Search

Categories

Links

Referers

I do not want Short Property Syntax Anyway

Jan 10 2007, 07:30:22 AM PST »Java»Language Comments [13]
Dear Santa,

Hans Muller just convinced me that I didn't want a short hand syntax for declaring properties after all. Hope it isn't too late.

Post a Comment:
Comments are closed for this entry.
Comments:

There are other proposals around which go beyond declaring simple properties, eg. http://jroller.com/page/scolebourne?entry=java_7_property_objects. The interaction between properties and frameworks is painful at the moment, and that is potentially a bigger target than just code generating a get/set.

Posted by Stephen Colebourne on January 10, 2007 at 08:28 AM PST #

Is that all you gathered from Hans Muller's post? A DO NOTHING attitude. I think his point was more that the current proposal serves poorly the java beans developers, and argues for one that that would be more geared toward the beans binding use cases. A far cry from the DO NOTHING approach that you seem to have quickly embraced.

Posted by Mike on January 10, 2007 at 09:11 AM PST #

This is probably the best idea. Don't understand me wrong. I love new language features. But adding properties to the language is not that trivial. There is much to consider here. I would hate, if properties were added the wrong way. Support properties the full way, or don't do it at all. And I would hate to use any operator other than DOT for accessing properties (I hate the arrow especially).

Posted by Fatih Coskun on January 10, 2007 at 09:53 AM PST #

Hmmm, does Hans have a secret costume of red clothes and a fluffy white beard?

Posted by Jonathan Gibbons on January 10, 2007 at 10:51 AM PST #

Well, Hans Muller not only demonstrates that current proposal for property support in the language is not enough, his example also shows how much boilerplate code could be generated by the IDE. The get/set methods are generated trivially, but the delegates for PropertyChangeSupport are also automatically generated (not sure about all IDEs but in IntelliJ this is called "Delegate Methods".

Posted by Eugene Vigdorchik on January 10, 2007 at 12:52 PM PST #

But if you are going to write the same code every time, to the point where you can just use code generators to write swaths of a program for you, why not incorporate it a a lower level. Is there a reason NOT to write a @Property annotation that will fulfill the same role? What is the difference between having your IDE generate the code and having a compiler do it, except that with the compiler doing it you don't have to see all that junk and look through it for the one case where you do need to do something different.

Posted by Ben on January 10, 2007 at 05:27 PM PST #

Thanks Santa Muller. :-) Better sense has prevailed. Victory for simplicity in the Java language!!

Posted by Bharath R on January 10, 2007 at 11:32 PM PST #

@Ben: this @Property is going to vary from one framework to another, so you will end up with the user not knowing exactly the code the compiler would generate. This drawback is addressed by aspects, but there are other problems with them. As for viewing and navigating the code, all IDEs allow for quick navigation in the file and folding code.

Posted by 84.52.111.196 on January 10, 2007 at 11:43 PM PST #

Dear peter,
i 've written my answer here.

Santa

Posted by Rémi Forax on January 11, 2007 at 08:26 AM PST #

I got a little bad feeling in current prototype.
interface base { public abstract property int val; }
class derived implements base {
    private int val;
    public int getVal(){ return val; }
    public void setVal(int v){ val = v; }
}
public class test {
    public static void main(String[] args){
        derived d = new derived();
        d.val = 0; //compile time error
    }
}
property is hidden by field declaration in remi's current prototype implementation. I think that is necessary to source level compatibility(new compiler can compile old class that implements interface which has property). However, this behavior is feeling bad to me. I worry whether property becomes the mass of such little bad feelings.

Posted by Michel Ishizuka on January 11, 2007 at 11:00 AM PST #

Michel, you are right. There is really a bad interaction.
The compiler could generate a warning in derived for that case. But that doesn't satisfy me.
It's perhaps time to change dot to another symbol :(

Posted by Rémi Forax on January 12, 2007 at 05:57 AM PST #

Michel, to be clear, this kind of shadowing exists since jdk1.0 but you are right that we can't retrofit property access that use gettter/setter to use qualified access without introducing this shadowing bug.

class base { public int val; }
class derived extends base {
    private int val;
}
public class ShadowingTest {
    public static void main(String[] args){
        derived d = new derived();
        d.val = 0; //compile time error
    }
}

Rémi

Posted by Rémi Forax on January 12, 2007 at 06:56 AM PST #

This is why I never wished for a short-hand syntax for accessing properties :-)

Posted by Peter von der Ahe on January 12, 2007 at 07:15 AM PST #

Java is a trademark of Sun Microsystems, Inc.
Copyright © 2006,2007 Peter von der Ahé