How to emluate "properties" in Java?
in [Java Programming]
|
From: Mike Schilling on 1 Mar 2010 09:31 Peter Duniho wrote: > Arved Sandstrom wrote: >> [...] >> Direction to good web articles or even a book or two is fine, and >> they can be as advanced as you think is necessary. I have in fact >> been following everything you've said in this thread, and the >> closest I see to any kind of explanation is a post of yours from >> about 2115 on the 25th of Feb. There you made two points: one about >> "more robust data binding", and one about the help that properties >> provides to GUI designers. I'm not particularly concerned about GUI >> designers, but perhaps you could direct me to some material that >> expands on the first point. > > You can infer conclusions about both points once you actually know > what _really_ happens when you write a property in C# (i.e. as > opposed to forming an opinion about properties in C# without actually > know what they are or how they work). For example, this method > becomes possible: > http://msdn.microsoft.com/en-us/library/aky14axb.aspx > That's the GetProperties() method from the System.Type class > (equivalent to Java's java.lang.Class class). There's simply no way > to write that method in Java simply by implementing properties as > conventionally named methods. I assume that you, or any other > reader, can correctly infer the value in such a method. The Java Beans infrastructure does exactly that: it assumes that methods that follow the conventions of public T getX(); public void setX(T); define properties, and uses reflection to find them.
From: Mike Schilling on 2 Mar 2010 03:00 Peter Duniho wrote: > Arved Sandstrom wrote: >> [...] >> Direction to good web articles or even a book or two is fine, and >> they can be as advanced as you think is necessary. I have in fact >> been following everything you've said in this thread, and the >> closest I see to any kind of explanation is a post of yours from >> about 2115 on the 25th of Feb. There you made two points: one about >> "more robust data binding", and one about the help that properties >> provides to GUI designers. I'm not particularly concerned about GUI >> designers, but perhaps you could direct me to some material that >> expands on the first point. > > You can infer conclusions about both points once you actually know > what really happens when you write a property in C# (i.e. as > opposed to forming an opinion about properties in C# without actually > know what they are or how they work). For example, this method > becomes possible: > http://msdn.microsoft.com/en-us/library/aky14axb.aspx > That's the GetProperties() method from the System.Type class > (equivalent to Java's java.lang.Class class). There's simply no way > to write that method in Java simply by implementing properties as > conventionally named methods. I assume that you, or any other > reader, can correctly infer the value in such a method. The Java Beans infrastructure does exactly that: it assumes that methods that follow the conventions of public T getX(); public void setX(T); define properties, and uses reflection to find them.
From: Peter Duniho on 2 Mar 2010 03:31 Mike Schilling wrote: > The Java Beans infrastructure does exactly that: it assumes that methods > that follow the conventions of > > public T getX(); > public void setX(T); > > define properties, and uses reflection to find them. Exactly. It _assumes_. If the conventions are not followed strictly, it may return "properties" that are in fact simply poorly named methods (where "poorly" is defined strictly based on the given naming convention�the names may or may not really be "poor"), and it won't return certain properties (including those that follow different Sun-approved naming conventions) because they don't happen to follow exactly _that_ naming convention. Thank you for making my point.
From: Thomas Pornin on 2 Mar 2010 08:23 According to Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com>: > First, I have said all along that the comparison is with a property > implementation depending _only_ on naming methods conventionally. Yeah, but that's irrelevant cheating, so I disregarded it. This branch of the thread is about how C# properties are "syntaxic sugar" or not, taking Java as point of comparison. In other words, whether adding C#-like properties would add something to Java which is not readily doable with existing syntaxic features of Java. Then you point out, although quite indirectly, that C# properties have an often-overlooked feature, which is that they are tagged with a flag which can be inspected at runtime through reflection. That flag is not impacted by how the property is named. Hence, it cannot be perfectly emulated with a naming convention, since this would induce the risk of collision. So you conclude that the "naming convention" (which is not a "language standard" as far as core Java is concerned, but it commonly used, for instance by JavaBeans) is not a complete substitute for C#-like properties. From which you infer that C#-like properties are not "syntaxic sugar". But wait, here we are not using Java as point of comparison, but instead Java-without-annotations. This is another language, a subset of Java, but not Java. There is the cheat. If we want to know whether C#-like properties, added to Java, would be syntaxic sugar or "something more", then we must compare it with what full-fledged Java provides. And the full Java provides annotations, which add the missing feature. Of course, a mere convention (on naming and annotating) can be overlooked. A compiler-enhanced construction such as the one provided in C# will imply less keystrokes, more portability, and less room for typographic errors. A compiler-enhanced construction which does that is called, precisely, "syntaxic sugar". It does not mean it is bad, or useless ! Only that omitting it does not substantially reduce the expressiveness of the language. (I understand that for some people, the expression "syntaxic sugar" has a dismissive undertone, so it is conceivable that some would fight to death before accepting that their pet feature could be described as such. But I personally strive not to have an emotional relationship with technical tools.) --Thomas Pornin
From: news.telesweet.net on 2 Mar 2010 09:27
On 3/2/2010 3:31 AM, Peter Duniho wrote: > Mike Schilling wrote: >> The Java Beans infrastructure does exactly that: it assumes that methods >> that follow the conventions of >> >> public T getX(); >> public void setX(T); >> >> define properties, and uses reflection to find them. > > Exactly. It _assumes_. If the conventions are not followed strictly, it > may return "properties" that are in fact simply poorly named methods > (where "poorly" is defined strictly based on the given naming > convention�the names may or may not really be "poor"), and it won't > return certain properties (including those that follow different > Sun-approved naming conventions) because they don't happen to follow > exactly _that_ naming convention. > > Thank you for making my point. And In C# you are assuming that what one programmer uses the property idiom for is exactly the same as what you are assuming they are using it for. If they don't follow the MS convention that you seem to be prescribing to, then you can have exactly the same problem in C#. -- Dan Giaimo |