Skip to main content

Remi's Property Proposal

Posted by rbair on January 24, 2007 at 9:39 AM PST

This is going to be a short one. To begin, be sure to read Remi Forax's blog about his refined property proposal. Read it? Good.

I think Remi is really on the right track, and I can't wait to get the next build of his javac compiler to play with it. In the week or so since I last blogged on properties, I've had a chance to consider and reconsider a bunch of alternatives. I came up with the same basic set of criteria that Remi has. But there are a couple things in his proposal that I'd tweak.

In my last entry, I made the case for needing the property feature to support auto-generating getters/setters so that current frameworks that rely on the JavaBeans spec continue to work with the new properties. Frameworks such as JSR 295 (beans binding), Spring, JPA, etc. jhook pointed out that we actually don't need to do this: as long as the java.beans.Introspector can read the new Property information in the class file, then frameworks would continue to work perfectly, without the need of introducing auto-generated getters/setters.

After thinking about it more, I am not in favor of auto generated getters and setters. It just feels wrong. You can read the source file and there will be no method "setFoo". Yet in another source file, there you are, calling "setFoo"! Called me old fashioned, call me over the hill. It just doesn't sit right.

Instead, I'm of the opinion that if properties are introduced in the language, they should be a clean implementation. Let the Introspector bridge the gap. And stick with Java's core language tenet: keep it readable!

This is why I really like Remi's proposal (which Joe Nuxoll also proposed at one point):

    public property String foo; #read/write property
    public property String bar get; #readonly property
    public property String baz set; #writeonly property
    public property String wow get() {return bar;} set(String w) {bar = w;} #property with code

He then goes on to talk about how to access a properties value. Here I part ways with Remi for a bit. I still think the "." accessor is the best choice. Thus:

    obj.foo = "Hello";
    String s = obj.foo;

One argument that has been made against the use of the "." notation is that it may have unintended side effects for the person making the call. Yes, it may. But then again, obj.setFoo("Hello") may have unintended side effects. If properties receive special attention in the javadoc (as I'm sure they would), then I see the unintended-side-effect argument to be much weaker. Want to know if there is a side effect? Read the docs! When you read the source code or docs for the class that declares the property, it is very clear what is going on.

Remi, Stephen Colebourne, Evan, and others have talked about a Property Literals (aka Property References, etc) which I think is a really, really great thing to be thinking about. Here is my minor tweak to Remi's proposal: use "#" as the operator instead of the ".". We already use # in the javadocs, so it would be a natural and consistent use. For example:

class Person {
    public property surname;
    public property givenName;
   
    /**
      * @return the #surname and #givenName, formatted
      */
    public String formatName(String msgFormatPattern) { ... }
}

...

String s = person.surname; //yields the value of the surname property
Property p = person#surname; //returns the Property object for the surname property
p = Person#surname; //also returns the Property object for the surname property
Method m = Person#formatName(String); //holy toledo! Returns a Method object!

As you can see, there are some benefits to introducing a new operator for this task. # to me, makes a lot of sense.

That's it for now. I hope to be able to chew on this problem a bit more.