Jacob Hookom's Blog

JSE 7 No Arrows Please

I'm finding so much of Java's APIs to be extremely literal and long-winded at times. While this produces self documenting code, I'd still like to see some better ideas for the getter/setter shorthand than '->'.

More on the topic here: Dion's Blog

I'm of the opinion that if you are willing to make a commitment to closures, then we do the same for properties-- something similar to C#. Spending time extending the long winded get/set convention is the wrong direction for the spec. Do everyone a favor and do properties right-- leaving the old Bean Property spec alone for APIs to accommodate and treating properties as a first class citizen in the metadata starting in SE 7.

Property[] p = class.getProperties();

Aside from the misread syntax of an assignment arrow ('->'), I can see a lot of people get confused by implying method associations by some naming convention. Actually introducing a literal property syntax into the spec will make code much more maintainable in the long run, than visual guessing games around field accessors.

Some senior developers may scoff at the thought of bean naming conventions as confusing, but from being on web/el/mvc dev lists for many years, you are guaranteed to get those people who have problems with reading properties because they didn't capitalize/lowercase the right letter.

Please SE folks-- think outside the box.

Comments

• Yeah, right. Esp. make *bound* properties first class citizens. I'm always reluctant implementing a whole addListener() bunch of code.

  Posted by: herkules on December 29, 2006 at 03:39 PM

• "If you evolve a language far enough you wreck it." - Josh Bloch

  Posted by: donjigweed on January 02, 2007 at 05:21 AM

• Too late ... Tiger teared down the walls :)

  Posted by: herkules on January 02, 2007 at 05:54 AM

• Unlike others, I favor the dot for property access, so that it looks just like instance variable access. The real big win here is in adding support for listener management--bound and possibly vetoable properties. Also, I would want the ability to concisely express all of this in an interface as well as in implementing classes.
  

  Posted by: coxcu on January 02, 2007 at 06:36 AM

• I agree with coxcu on the dot notation. In Python this is handled very elegantly. You use the dot notation at any time, the implementation determines if this uses a getter/setter or not.
  The upshot of this is that you can start simple (everything public) and change this later without the consumer of the interface having to make any code changes. It does save quite a bit of typing too of course :).
  

  Posted by: jmelchio on January 02, 2007 at 07:37 AM

• the reason of not using Dot is that it will not break the backward compatibility consider:

  class A {
  public int f; // old code
  public int getF() { // old code
  return f;
  }
  public property int f;// new code
  }

  so what is (new A()).f refer to?

  Posted by: fcmmok on January 02, 2007 at 10:03 AM

• that's kind of like saying we couldn't add Enums because:public String type would conflict with public enum type. Why couldn't we use dot accessors?

  Posted by: jhook on January 02, 2007 at 10:14 AM

• fcmmok, "so what is (new A()).f refer to?"
  The property modifier on a field could imply that the field is private. The property modifier could also imply the usage of a final boxing instance, so that listeners could be easily notified.

  Posted by: coxcu on January 02, 2007 at 01:09 PM

• I dislike properties. The cons outweight the pros. If you are not using your IDE to generate your setters and getters, then yes poperties look attractive. But they only solve for the person "writing" the code. Not readability, maintainability, which are far more important and actualy have a greater cost in the SDLC.

  Posted by: atehrani on January 02, 2007 at 02:55 PM

• I share the opinion of atehrani.
  Code like the one of getters and setters isn't written by hand these days. So, why simplify it?
  BTW; if you want to change the behaviour of a getter or a setter, it's much easier if you adapt the generated code than using a completely different syntax than when you declared the properties.The language Java is good as it is. Let's not mess with it.I see much more room for improvement in the class library: wide spread use of enums, eliminate deprecated methods, ...

  Posted by: luethjec on January 02, 2007 at 10:28 PM

• "If you evolve a language far enough you wreck it." - Josh Bloch
  Exactly, and Sun is hard at work doing exactly that with Java in their mad drive to include everything that any other language anyone claims to like has.
  They should just leave it alone, rather than trying to turn it into C--RuPy#.

  Posted by: jwenting on January 02, 2007 at 11:06 PM

• I agree that there needs to be more to property support than just an operator for property access. But let's not get hung up on the arrow...

  http://weblogs.java.net/blog/cayhorstmann/archive/2007/01/arrows_in_the_b.html

  Posted by: cayhorstmann on January 07, 2007 at 03:30 PM

• NO NO NO to arrows

  Think of a newbie trying to learn Java. Already they have a huge amount to learn. Adding yet another symbol is going to make the learning curve even steeper.

  If you do want properties, then at least do it in a way that is transparent. If I'm not ready to use them / learn about them , then at least they won't get in my way.

  Paul , Technology in Plain English

  Posted by: paulbrowne on January 19, 2007 at 03:21 AM

This work is licensed under a Creative Commons License.