How to emluate "properties" in Java?
in [Java Programming]
|
From: Robert Klemme on 25 Feb 2010 17:01 On 02/25/2010 06:15 PM, Lew wrote: > Don't confuse the Platonic ideal with the shadows on the cave wall. LOL Thanks for making my day! Now if I could only get out of this dark spot... :-) Cheers robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/
From: Roedy Green on 25 Feb 2010 18:26 On Thu, 25 Feb 2010 20:38:01 +0800, Michael Tsang <miklcct(a)gmail.com> wrote, quoted or indirectly quoted someone who said : >Some languages have native support for property, e.g. C#, Python, PHP. >Although C++ doesn't, I always emulate them by defining helper classes that >overload the copy constructor and the conversion operator. In Java, there is >no operator overloading, how do I emulate them? If I can't do this, I will >have trouble doing OO in Java. Gosling is a bottom up the JVM-is-Java man. His philosophy is "if there is a way to express the solution in Java, the job is done." In his view, Delphi-like properties would do nothing to the JVM, therefore they would be frivolous syntactic sugar. I strenuously disagree. A verbose program is a buggy program hard to proofread and wasteful of time to compose. Getters and setters are infantile syntax. What to do about it? 1. see http://mindprod.com/project/scid.html 2. use IntelliJ which at least will generate reams of getter/setter crud for you. http://mindprod.com/jgloss/intellij.html 3. Use JAXB which will also generate getter/setters from XSDs. http://mindprod.com/jgloss/jaxb.html 4. use C# 5. see http://mindprod.com/jgloss/bali.html -- Roedy Green Canadian Mind Products http://mindprod.com The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. ~ Douglas Adams (born: 1952-03-11 died: 2001-05-11 at age: 49)
From: Arne Vajhøj on 25 Feb 2010 19:30 On 25-02-2010 07:38, Michael Tsang wrote: > A property is defined as a member that is read and written like a field, but > the read and the write actually calls the getter and setter. > > http://en.wikipedia.org/wiki/Property_(programming) > > Some languages have native support for property, e.g. C#, Python, PHP. > Although C++ doesn't, I always emulate them by defining helper classes that > overload the copy constructor and the conversion operator. In Java, there is > no operator overloading, how do I emulate them? If I can't do this, I will > have trouble doing OO in Java. You use explicit get and set methods and calls. There is a convention for that. And you should follow the convention, because various tools will expect that convention to be followed. Arne
From: Joshua Cranmer on 25 Feb 2010 19:57 On 02/25/2010 06:26 PM, Roedy Green wrote: > I strenuously disagree. A verbose program is a buggy program hard to > proofread and wasteful of time to compose. Getters and setters are > infantile syntax. There is some virtue in verbosity: it means you can identify patterns more easily. Right now, in Java, "a.b = 5" is always going to set a field in the object A to 5. If you had properties, the same syntax could also mean to call a function with an argument of 5, which may or may not set a field to 5. It could also just decide to sneer in your face for the heck of it. Let's compare: a.b = 5; a.setB(5); You've saved a grand total of 2 characters at the cost of hiding a method call, which impairs the ability of a reader to quickly glance over code and see what is happening. You've also made syntax ambiguous, since whether or not `b' is a field access or a method call depends on the type of `a' and the identifier `b' represents. [1] There is another example of where verbosity is useful. In the English language, the information entropy is roughly ~1-1.5 bits/letter, so we actually only theoretically need about 3 letters to keep text on average the same size. Why don't we? Bcs it enbles us to rd txt whn som letrs r mssng or malfermed. [1] I do realize that a.b is already ambiguous syntax, thanks to Java overloading the meaning of the `.' to be both a scope resolution operator (e.g., java.io.Serializable) and a member access operator. In this case, I would classify nested classes as falling under `scope resolution' (so if we had used '::' for scope resolution, Map.Entry would be `Map::Entry'). The decision to overload `.' is not one I'm particularly thrilled with. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
From: Peter Duniho on 25 Feb 2010 20:15
Joshua Cranmer wrote: > There is some virtue in verbosity: it means you can identify patterns > more easily. And other patterns are harder to identify. > Right now, in Java, "a.b = 5" is always going to set a field in the > object A to 5. If you had properties, the same syntax could also mean to > call a function with an argument of 5, which may or may not set a field > to 5. It could also just decide to sneer in your face for the heck of it. > > Let's compare: > a.b = 5; > a.setB(5); How does the second line of code in any way tell you what the method is doing? If anything, a property carries with it a strongly implication that the _object_ itself will be modified. A method named "setB()" could do anything. Granted, in Java we have the convention that a method named "setX" is going to set some property-like state in the object. But then you're just back to the whole property thing. 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". Another convention is to not have any public fields at all. So only within the class would there even be a chance of ambiguity, and of course by following the above convention, that's removed as well. That said, if all this were was about syntactic sugar and naming conventions, I'd agree. Properties wouldn't add much, if anything, over simply having a naming convention in Java. Note, however that that's not really the case. Using .NET as the example again, properties are full-fledged class members uniquely different from other kinds of members. This enables, for example, a more robust data binding model, where you can specify the name of the property and be assured that you are really getting a property, rather than just a method that happens to look like the method that would exist had that property actually been present. Going the other direction, it enables in GUI designers (don't even get me started at the vast gulf between designers for .NET Forms and WPF applications, as compared to those available in Java) the ability to confidently display property values to be initialized as part of a designed object, again without worrying about whether something is displayed because it just happened to look like a property when it wasn't, or failing to display something because it's still basically a property but for some reason someone failed to follow the correct naming convention. In some situations, I'd agree that verbosity can help improve communication through redundancy. It's basic error-detection and -correction concepts. But when there are other ways to convey the same information, or especially when one can change the situation so that there's no longer the ambiguity in the first place, IMHO that's a better approach as compared to just repeating oneself. :) Pete |