Embarrasing myself Google in 2007
Dec 28

a->properties are special in Java 7

Java, Ruby, Tech Add comments

I am not sure how I feel about a->foo = b->foo, having a magic -> operator for properties.

In theory I actually like syntactic sugar. It can be a pain to learn, but once you do you have more power in your own hands. On the other hand I really hate having > as part of an operator (which bugged me about generics). The peeve? Working with HTML (blog posts, html docs, etc) make it a royal pain. How many entries have you seen that make no sense and then you realise the the generic stuff wasn’t escaped. Grr.

I also prefer to think of sending messages to objects. If the message happens to correspond to a property, that is great. a.foo in Ruby could mean many things hidden behind various implementations, and there is no need to call out THIS IS A PROPERTY.

And then of course we like being able to method_missing and more, so a.foo may not even exist yet.

20 Responses to “a->properties are special in Java 7”

  1. Bob Lee Says:

    TMK, there isn’t even a JSR yet, so I wouldn’t worry about it too much. The final design will most likely be very different.

  2. Kirk Says:

    The spec lead is writing at the moment and this operator *is* on the table. Sorry about the redirect Dion but I also blogged about the subject yesterday and it includes a link to Danny Corwards talk in Prague. It is worth a listen to.

    The scarier thing is modules. Modules look like yet another way to slow down the code-deploy-debug cycle. I don’t know enough to blog just yet but….

    Cheers,
    Kirk

  3. Stephen Colebourne Says:

    Yes the -> operator is terrible, its difficult to type and not great to read. Secondly, and more importantly, its just a fraction of a real EL syntax. Now whether its worth adding an EL syntax to Java now is highly debatable…

  4. Doug Says:

    If they don’t use a.foo for properties (like everyone else), then the java designers might as well pack it up and go home. There is no technical reason that “.” would not work. See for example ruby, python, C#, boo, etc. Properties are supposed to make things simpler, not more verbose. I think it would help if pre-existing methods that start with “set” or “get” can be recognized as property accessors, too. The java standard library would instantly become a lot easier to use.

  5. Doug Says:

    p.s. You might want to change your blog to show the URL of a commenter rather than their email address. Putting plain email addresses on webpages lead to a lot of spam.

  6. hookomjj Says:

    why are they still wasting time on extending the bean property convention? If you are going to introduce syntax for bean properties as first-class citizens within classes, then do it right with C#-ish syntax. The BeanProperty Introspector API did it’s job, but I can see the whole thing snowball into an unmaintainable mess if they continue to tweak/modify that legacy *convention*.

  7. messi Says:

    Only using the “.” for property assignment will break old code. You have to give field assignment a higher precedence. But there’s (almost) always a private or protected field with the same name as the property and that makes direct property assignment this way completely useless. Other languages, like C# or Ruby, were designed to handle properties from the beginning.

    Gosling suggested keeping the “.” and using the “:=” as assignment operator. But this works just for setters.

    So, we need to introduce something like the arrow: “obj->prop”, or similar to Ruby with switched meaning: “obj.@prop”, or Smalltalk-like “obj.:prop”. (Just “:” doesn’t work because of “labels”.)

  8. messi Says:

    Sorry, Gosling’s proposal is for something else.

  9. Alexander Says:

    Just make all bean property fields public, then you have a.foo syntax today (and yesterday).

    Think about it. What is encapsulated by this piece of code?

    private String foo;

    public String getFoo() { return foo; }

    public void setFoo(String foo) { this.foo = foo; }

  10. kirk Says:

    Hi Alexander,

    I’ve thought about it and blogged about it and even had a MS person comment on the C# syntax. Rather than siphon off of Dion’s blog I’ll just repeat what I said there… here.

    The mistake people make with encapsulation is that they only think of assignment. Encapsulation is about information hiding, not only assignment but typing information. Lets take your example for instances

    you have

    public String getFoo() { return foo;}
    public void setFoo( String foo) { this.foo=foo; }

    Now lets change the type of foo from String to Foo. The code could change to;

    public String getFoo() { return foo.toString();}
    public void setFoo( String foo) { this.foo= new Foo( foo); }

    Ok this example is a bit trivial and it isn’t something you are likely to do. However lets apply this to say… a collection type and I think you start to get a better picture about how information hiding (encapsulation) can be useful. Also, covariant return types would also be useful because it would allow me to add this method

    public Foo getFoo() { return this.foo; }

    In fact one has to do so much futzing with typing one has to wonder if the Smalltalk/Ruby crowd are on to something that the type happy crowd are trying to hack their way to.

    Cheers,
    Kirk

  11. Ired Says:

    Another two-character symbol which some may view as no less than an attempt to derail Java, is the use of the ‘=>’ as part of the closure declaration.

    See http://www.artima.com/forums/flat.jsp?forum=226&thread=189212&start=15&msRange=15

  12. Mileta Cekovic Says:

    We can use begin property names with uppercase: a.Foo = b.Foo;
    As common Java naming convention is to begin method and variable names with lowercase, the code that could be potentially broken is minimal.

    Also, if syntax for defining getter and setter methods is about to be simplified too, please do not make the same mistake as M$ and provide separate access control modifiers for getter and setter.

  13. Cay Horstmann Says:

    There is no need to use the -> operator for property access. My graduate student Alex Alves did a nice implementation using the .@ syntax: item.@price = product.@price instead of item.setPrice(product.getPrice()). See http://weblogs.java.net/blog/cayhorstmann/archive/2007/01/arrows_in_the_b.html

  14. craft Says:

    interesting

  15. Tom Rossen Says:

    Mileta – the latest version of C# corrects that problem: setters and getters in properties can have distinct visibilities.

    As one who works in both worlds, I think your suggestion to capitalize properties is terrific.

  16. zalapivy Says:

    cetos kavymicy gukma
    the http://ug3h0wi.info/sitemap1.html [url=http://egijqa5.info/sitemap1.html ]in[/url] off http://qctrrag.info/sitemap2.html [url=http://whwkja3.info/sitemap1.html ]a[/url] He http://ug3h0wi.info/sitemap2.html [url=http://llltfuf.info/sitemap2.html ]careless[/url] rutuh

  17. replica handbags Says:

    amazing,thanks for sharing!!

  18. replica handbags Says:

    thank you again!

  19. ncper world Says:

    that is great.my web is http://seojishu.zhan.cn.yahoo.com

  20. Replica handbags Says:

    What is the number before 3, thanks for sharing,generous blogger

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'