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.
December 28th, 2006 at 11:47 am
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.
December 28th, 2006 at 5:12 pm
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
December 28th, 2006 at 7:15 pm
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…
December 28th, 2006 at 9:16 pm
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.
December 28th, 2006 at 9:18 pm
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.
December 28th, 2006 at 11:17 pm
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*.
December 29th, 2006 at 12:32 am
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”.)
December 29th, 2006 at 1:41 am
Sorry, Gosling’s proposal is for something else.
December 29th, 2006 at 4:21 am
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; }
December 29th, 2006 at 3:11 pm
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
December 29th, 2006 at 4:23 pm
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
January 3rd, 2007 at 3:49 am
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.
January 7th, 2007 at 5:35 pm
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
April 5th, 2007 at 12:06 pm
interesting
July 5th, 2007 at 9:51 am
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.
September 8th, 2007 at 2:39 am
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
May 19th, 2008 at 1:48 am
amazing,thanks for sharing!!
June 23rd, 2008 at 4:30 pm
thank you again!
June 25th, 2008 at 7:57 am
that is great.my web is http://seojishu.zhan.cn.yahoo.com
May 27th, 2009 at 6:32 pm
What is the number before 3, thanks for sharing,generous blogger