How to emluate "properties" in Java?
in [Java Programming]
|
From: Peter Duniho on 28 Feb 2010 19:56 Arved Sandstrom wrote: > The term "syntactic sugar" has nothing whatsoever to do with differences > in compiled output. It most certainly does have to do with that. One of the biggest benefits of having built-in property support is for what's possible _after_ the code has been compiled. You cannot ignore the compiled output and still expect to comprehend how properties are useful beyond simple naming conventions. > I agree entirely with your definition - it's the one > I'm using. And that definition has nothing to do with object > code/IL/bytecode differences. If you think that's true, then you aren't using the same definition I'm using. > The fact is that you can replace every use of a C# property with either > a public member field and/or a public method. No, you can't. If you do that, then you sacrifice a big part of what makes properties useful. > That's why properties are syntactic sugar. No, it's not. Pete
From: Peter Duniho on 1 Mar 2010 03:19 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. Or more explicitly, consider the following type: class Test { public string PropertyA { get { return "PropertyA"; } set { } } public string getPropertyB() { return "PropertyB"; } public void setPropertyB(string str) { } } The generated IL is as follows: .class auto ansi nested private beforefieldinit Test extends [mscorlib]System.Object { .method public hidebysig specialname instance string get_PropertyA() cil managed { // Code size 11 (0xb) .maxstack 1 .locals init ([0] string CS$1$0000) IL_0000: nop IL_0001: ldstr "PropertyA" IL_0006: stloc.0 IL_0007: br.s IL_0009 IL_0009: ldloc.0 IL_000a: ret } // end of method Test::get_PropertyA .method public hidebysig specialname instance void set_PropertyA(string 'value') cil managed { // Code size 2 (0x2) .maxstack 8 IL_0000: nop IL_0001: ret } // end of method Test::set_PropertyA .method public hidebysig instance string getPropertyB() cil managed { // Code size 11 (0xb) .maxstack 1 .locals init ([0] string CS$1$0000) IL_0000: nop IL_0001: ldstr "PropertyB" IL_0006: stloc.0 IL_0007: br.s IL_0009 IL_0009: ldloc.0 IL_000a: ret } // end of method Test::getPropertyB .method public hidebysig instance void setPropertyB(string str) cil managed { // Code size 2 (0x2) .maxstack 8 IL_0000: nop IL_0001: ret } // end of method Test::setPropertyB .method public hidebysig specialname rtspecialname instance void .ctor() cil managed { // Code size 7 (0x7) .maxstack 8 IL_0000: ldarg.0 IL_0001: call instance void [mscorlib]System.Object::.ctor() IL_0006: ret } // end of method Test::.ctor .property instance string PropertyA() { .get instance string TestConventionalProperties.Program/Test::get_PropertyA() .set instance void TestConventionalProperties.Program/Test::set_PropertyA(string) } // end of property Test::PropertyA } // end of class Test Noting, of course, the key difference between the "method-only" property "PropertyB" and the "property-declared" property "PropertyA": specifically, the class gets an _actual_ ".property" member for the "PropertyA" property. This property member is useful in a variety of contexts, support for data binding being just one. There is no other language feature in C# that allows you to declare and emit that special ".property" class member, nor can you achieve the same functionality (in either Java or C#) simply by using some particular naming convention for plain methods. In the context of data binding, the above feature allows a variety of things. But here's one example: http://msdn.microsoft.com/en-us/library/system.windows.forms.listcontrol.displaymember.aspx That's a property on the ListControl base class that allows you to specify the property used to generate whatever happens to actually be displayed in the ListControl for any given item stored as an element of the ListControl's list. It works because the ListControl class can reliably convert the string into a PropertyInfo object that allows the value of the property for any object instance to be retrieved. You can accomplish the same end-result in Java, but not in a way that ensures you're really specifically dealing with properties, nor in a general way that ensures you always have access to (i.e. can identify) every property present in a class. I.e. it's not precisely the same functionality, even if what the user sees in the end is the same. > P.S. We may as well not argue about the definition of syntactic sugar. > :-) What I understand to be the definition of syntactic sugar, as also > defined by Wikipedia, and as I've seen innumerable people use it, never > mentions differences in intermediate or object code. You are reading that definition much differently than I do. From the introduction: Specifically, a construct in a language is called syntactic sugar if it can be removed from the language without any effect on what the language can do: functionality and expressive power will remain the same. If you remove properties from C#, the language can no longer accomplish the same functionality it could before. Furthermore, the specific functionality it can no longer accomplish is _specifically_ related to the _compiled_ output. And more generally speaking, _any_ language feature that exists specifically to affect the compiled output (i.e. it's not just something that you could simply write differently using other features of the language and still get the same compiled output) is by definition not going to qualify as "syntactic sugar", and further more it won't qualify _specifically because_ of the difference in the _compiled_ output. In fact, I think you'd be hard-pressed to find a language feature that fails to qualify as "syntactic sugar" and yet _can_ be written using some other feature(s) of the language to accomplish the same _compiled_ output. In other words, syntactic sugar very much has a LOT to do with what the compiled output is. If you would prefer to not argue about the definition of "syntactic sugar", that's fine with me. But if you choose to hold that position, you need to actually not argue about the definition of "syntactic sugar". > I might also add, one might want to be careful about striking a note of > infallibility. I have no idea what the above is intended to mean. I've never ever suggested I'm infallible. > In the same post of yours I mentioned, you say: > > "Note that other naming conventions solve the question of distinguishing > a property from a field. For example, the .NET naming convention > requires properties to start with a capital letter, and field names with > a lower-case. Thus, "a.b = 5" is always setting a field, while "a.B" is > setting a property"." > > In fact this is not true. An extremely common .NET convention is > specifically for public member fields and properties both to be > capitalized. Incorrect. That's not an accepted convention, never mind "an extremely common" one. There is a single, Microsoft-supported .NET naming convention, and it specifically advises that fields should not be capitalized. From http://msdn.microsoft.com/en-us/library/ms229043.aspx: Do use Pascal casing for all public member, type, and namespace names consisting of multiple words. Note that this rule does not apply to instance fields. > More precisely, I've almost always seen properties > capitalized, and I've seen reams and reams of C# that has public member > fields capitalized, including a lot of source by authoritative writers. If an author recommends for .NET programs having public fields at all, never mind capitalizing them, they are by definition not authoritative. Both recommendations would be contrary to the official conventions (something surely the readers of this newsgroup would appreciate, given how religiously they adhere to Sun's Java conventions). Pete
From: news.telesweet.net on 1 Mar 2010 04:34 On 3/1/2010 3:19 AM, Peter Duniho wrote: > Arved Sandstrom wrote: <snip> > You can accomplish the same end-result in Java, but not in a way that > ensures you're really specifically dealing with properties, nor in a > general way that ensures you always have access to (i.e. can identify) > every property present in a class. I.e. it's not precisely the same > functionality, even if what the user sees in the end is the same. Functionality is defined by what the end-user sees. If what the end-user sees is the same, then it is the same functionality. -- Dan Giaimo
From: Arved Sandstrom on 1 Mar 2010 05:43 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 [ SNIP ] Good stuff, thank you. I will digest all this at some leisure. > >> P.S. We may as well not argue about the definition of syntactic sugar. >> :-) What I understand to be the definition of syntactic sugar, as also >> defined by Wikipedia, and as I've seen innumerable people use it, >> never mentions differences in intermediate or object code. > > You are reading that definition much differently than I do. [ SNIP ] > > If you would prefer to not argue about the definition of "syntactic > sugar", that's fine with me. But if you choose to hold that position, > you need to actually not argue about the definition of "syntactic sugar". Yeah, let's leave it at that. We clearly disagree, but it's not relevant to this discussion. >> I might also add, one might want to be careful about striking a note >> of infallibility. > > I have no idea what the above is intended to mean. I've never ever > suggested I'm infallible. > >> In the same post of yours I mentioned, you say: >> >> "Note that other naming conventions solve the question of >> distinguishing a property from a field. For example, the .NET naming >> convention requires properties to start with a capital letter, and >> field names with a lower-case. Thus, "a.b = 5" is always setting a >> field, while "a.B" is setting a property"." >> >> In fact this is not true. An extremely common .NET convention is >> specifically for public member fields and properties both to be >> capitalized. > > Incorrect. That's not an accepted convention, never mind "an extremely > common" one. [ SNIP ] We'll have to disagree. We must be looking at almost completely non-overlapping code and articles and books over the past X years. And I don't make a habit of reading SAMS or Que books, or RoseIndia style websites either. I can see with my own eyes that people are widely Pascal-casing - not camel casing - instance fields, including public instance fields (and BTW, MS also recommends strongly not to do public instance fields but it's very common to do just that). I didn't say MS .NET convention; I said _an_ extremely common .NET convention. "An", not "the". Extremely common == accepted. And I'll stand by that observation. Not much point in beating this one to death. I use the MS convention myself, and that's what matters to me. AHS
From: Thomas Pornin on 1 Mar 2010 08:29
According to Peter Duniho <NpOeStPeAdM(a)NnOwSlPiAnMk.com>: > 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. But it is simple enough to do with annotations. Simply define this: @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) @interface Property { } and tag getters and setters with the '@Property' annotation. If 'm' contains a reference to a Method instance, then just call m.isAnnotationPresent(Property.class) to see if the method has been so annotated. What you describe as being a special characteristic of properties (with regards to plain methods) is just a simple boolean metadata accessible at runtime through reflection. Java has a generic support for metadata, known as "annotations". This means that C# properties are a mere syntaxic convenience over the get+set naming convention along with an annotation, as shown above. (You may argue that the syntaxic convenience is more fool-proof against typographic errors, and that would be true. But that's what syntaxic conveniences are about.) (I am not using the traditional "syntaxic sugar" expression, because I am not American. That expression is based upon the idea that sugar is the incarnation of happiness, which is, as tastes go, quite childish. However, an expression which would be more to my liking would be "syntaxic sausage", but I fear that it would not be appropriately understood.) --Thomas Pornin |