The Great Property Debate

Why this new syntax? There may be some subtle (or not so subtle) reason I can't see at 8am, but I don't understand why we can't just overload the dot operator. That seems much more intuitive and makes it possible to change direct field accesses to properties without changing any client source code. You could even add some special magic to class loading where accesses to fields that are not visible result in an attempt to find a property of the same name before failing. Then you could go retrofit non-properties after the fact, meaning that use of public fields would be fine because you can always change them to properties later.

In his example, Danny Corward seems to plead for a mean to lighten the syntax needed to pass a value from one public variable to another one. This is in fact a call for the introduction of "operator overloading" into the Java language.
It's great to see some people at Sun realizing what a language *must* implement to be called an object oriented language.
See for example the article Conventions for Arithmetic Operations in Java for a discussion on how to deal with Java's lack of operator overloading. See also, the other article on the same site about Java : www.idinews.com/indexJava.html

Jérôme Radix.

The change from an instance variable to a property needs to be transparent not only from a compiler perspective, you need also to be transparent from the reflection API perspective. Then you can start with a public instance variable and evolve to a property when you need to add encapsulation to it.

Cay writes:

Using just the dot is unfortunately a minefield. You'd have to look closely what item.quantity means. Is there an accessible field quantity? Is there a quantity property? Who wins if both are present? Or is that illegal? I am sure that one can cook up a set of rules, but is it worth it? Why are people so attached to the dot?

Ok, apparently the Java community has too many code monkeys. So let me break it down for you.

NO! We don't need the new syntax for property accessing. If your IDE can't generates the 'get' with two key strokes, then stop using notepad.

NO! We don't need Operator overloading. For those morons that are ready to say "But it can help make your code easier to read." Or "It makes logical sense in terms of an OOD to override the operators." Don't fool your self. Think in terms of power-to-weight ratio. Does the new features power out weigh the complexity factor? I don't think it does. Java became as popular as it did because it was simple. You don't low level addressing that pointers in C++ provide, you don't need the new -> property accessor, you don't need a broken broom stick jammed six inches inside of your anus and no, you don't need to attract every C++ or Ruby left over that's looking to rant about how Java is lacking something.

Let's stop running around telling people how great we type by bashing ours on the keyboard.

Best Regards,
Richard L. Burton III

Yep. We should stick to solving problems that really need solving. But this is typical. What we are doing here is a perfectly normal human meta-design mistake I call Building the Menus (see third comment).

I totally agree for operator overloading.
At least, with Java, when I read "x = x + 6", I know
what's happening, without browsing any class or variable declaration, and don't want it to change.

For property, if done properly it can be interesting, perhaps increansing readability.

I think property could as well help better design and refactoring. When someone does a myObject.attribute call and then this attribute has to change, then properties are most welcomed.

Indeed, the call to this attribute wouldn't change but behind we would easily be able to do the required trick.

Nowadays, if my attribute changes (for example of type...), then I've to change all the line where myObject.attribute was made. In terms of encapsulation it's pretty poor no ? Similarly, who knows whether someone has called it directly somewhere in the code ?

BTW, why are some asking for a new -> operator ? The reason is simple : the cost of making a call directly to an attribute would be a lot less than calling a property. There, without a new operator, one would not know just by reading whether it's an attribute call or a property call.Hence the new operator.

ZedroS

without a new operator, one would not know just by reading whether it's an attribute call or a property call

I'm just poiting some justifications of this -> I've seen around, nothing else !

On a personnal note, I would also add that the performance overload of using a property insteand of a normal attribute shouldn't be an issue for the Average Joe Developer, since most of the time performance isn't really an issue (but design for sure, as usual;)).

But then, who am I to comment on a forum without bothering to spam the JSR members ? I did vote for the issue in the Sun database however. I think it could help reduce maintenability issue and provide good value.

So you?re arguing that this simple change will stop world hunger or some how provide clarity to tons of crappy code? Like Jonathan said, we have bigger fish to fry right now. I?d rather debate the removal of checked exceptions than this! I?m not advocating the removal of them, but I believe that conversation alone will produce some very interesting lines of thought.

Conclusion:

CrappyCode cc = new CrappyCode();

cc->doesNothing = "that the following can do.";
cc.setDoesNothing("That the following can do.");

The second reads better.


Best Regards,

Richard L. Burtton III

Richard: Actually, I don't think the choice is simply checked or unchecked exceptions. Neither works and I believe there are other, better ways to do this.

It'd be ridiculous to use anything other than the dot operator for properties. I would be utterly shocked if they moved forward with using alternate operators purely for readability. Properties should *look* like member assignment 'foo.bar = "hello";', developers are already familiar with that behavior. Introducing '->' means a whole different switch of thought on behaviors when really, properties should be as simple and visually seamless as possible.

The property syntax looks like Delphi. I strongly like the idea of the property keyword. It makes the code more terse. This is a good thing.

The getter and setter are implicitly defined with the property keyword. Cool!

I can't stand the "->" operator. I think the dot operator should be used.

Here is how I think it should work....

If you define a property, when you use the dot operator you should always get the property. E.g., <code>foo.bar</code> should always resolve to the property *never* to the field <code>foo</code>.

In fact the only time you can access the field should be inside of the class. And if you use the <code>this.bar</code> you access the property but if you are inside the class and you use just an unqualified <code>bar</code> you will access the field.

If you don't use the <code>property</code> keyword than access to field vs. property should be the same as it always was. This makes the dot usage backwards compatible for code that predates Java 7.


My $0.02.

Hey Rick, I'd like to first say it's great to see you not talking about JSF! Secondly your suggestion would break a lot of existing code. Yes, unfortunately the Java world is full of people that run around telling people that the pot hole in the street is really their ass. So expect a ton of people out there to define public properties with the thought it'll be a great improvement in terms of speed. ?Hey, if there is not method invocation, it'll be faster!?

With that being said, most people don't know how powerful the java compiler really is and the things it does for optimization during this process.

Best Regards,
Richard L. Burton III

Hey Jonathon,

What are your thoughts on checked vs. unchecked exceptions?

Richard L. Burton III

I totally agree for operator overloading.
At least, with Java, when I read "x = x + 6"
I know what's happening

The change from an instance variable to a property needs to be transparent not only from a compiler perspective, you need also to be transparent from the reflection API perspective. Then you can start with a public instance variable and evolve to a property when you need to add encapsulation to it.

public class Boat {
    property String name;
    property RigType rigType;
    property int berths;
}

public class Boat {
    @Property public String name;
    @Property public RigType rigType;
    @Property public int berths;
}

Really guys, what does this buy us? Are we aiming to bring clarity to the syntax, make the language less verbose or both? If Java must change this, then they should consider something on the lines that Patrick pointed out. Ideally, we want to reduce the verboseness of get/set on our classes, but at the same time, we don't want to be intrusive to the clarity of our code (Take C# for example). Introducing a new keyword would be extremely rare, especially the keyword property. Why? I know for sure that I've used the word 'property' has a variable before and there's no sure way to introduce a keyword without breaking existing code. That's why Java reserved some keywords such as goto.

Using annotations wouldn't be a solution either. Why? Annotations are just a way to bind meta data to a class and you would need to extract that meta data in order to make any real use of it. Unless Sun finds a creative way to modify the ClassLoader and dynamically enhance the class when it's loaded like Patrick pointed out. Either way, I really don't see the benefit of even attempting this. The power-to-weight ratio is rather low.

Best Regards,
Richard L. Burton III

I know for sure that I've used the word 'property' has a variable before and there's no sure way to introduce a keyword without breaking existing code. That's why Java reserved some keywords such as goto.

package com.example;
version 7.0;

public class Boat {
    property String name;
    property RigType rigType;
    property int berths;
}

Using annotations wouldn't be a solution either. Why? Annotations are just a way to bind meta data to a class and you would need to extract that meta data in order to make any real use of it. Unless Sun finds a creative way to modify the ClassLoader and dynamically enhance the class when it's loaded like Patrick pointed out.

Honestly, all of this boils down to "power-to-weight ratio". By adding this level of complexity (Context-Aware keywords or a version number. I also believe the version number solution would lead to a lot of bugs.) or any of the other proposed solutions, do nothing but increase the weight ratio and provide very little power. I'm sure there are other area?s of the Java language that can be improved.

Patrick, I'm not saying this can?t be done. I'm just stressing the fact that this isn?t needed. If we must add something, then let's add support for strings within a switch statement or remove the need for the keyword "break" in the switch statement. That'll surely clean up some very verbose code.

Best Regards,
Richard L. Burton III

FTR, I'm not defending the idea of adding uniform access syntax to Java. While I do think that uniform access is a great concept, I agree that it's a big change to an increasingly-brittle language. There are pros and cons to such a language mutation, and I don't have enough background on all of the issues to really have an opinion. The goal of my earlier post was to point out that adding a uniform access syntax does not necessarily mean that we need to change how fields and methods currently work in the language.

Also, my comment about the utility of a means to specify a source version in a Java source file isn't based on the needs of uniform access. A version keyword (or some other means of communicating version information, such as an annotation on the package declaration or the class) would have allowed Java to add a new 'annotation' top-level keyword instead of using '@interface'. It would allow us to gracefully add closures without worrying about syntax collision with esoteric source constructs supported in earlier JDK versions. It would even allow Sun to change the switch statement in some way to allow automatically-breaking case blocks. Generally-speaking, if we had source-level version data in the source file, the Java source language syntax could change in non-backwards-compatible ways without compromising bytecode-level compatibility. Adding version data might fail your power-to-weight test in its own right, but it would enable lots of significant language-level changes in the future.

let's add support for strings within a switch statement

Well it's been refreshing talking to you Patrick. I haven't considered the idea of supporting switching on any object based upon the equals method. It seems fitting since it's more OO and gives greater support for other data types without adding any complexity to the language.

Best Regards,
Richard L. Burton III

I don't think it will break a lot of existing code. You do. So please enlighten us....

For the record... I work with JSF, Tapestry, Spring MVC, Spring, Hibernate, etc. a lot. I don't think I am focused on JSF like you think I am. I don't dislike it. JSF has its strengths and weaknesses. JSF 1.2 fixed a lot of those weaknesses. I look hopeful towards JSF 2.0.