Re: the Java Lang will support Properties in Futuere?
- From: Joshua Cranmer <Pidgeot18@xxxxxxxxxxxxxxx>
- Date: Sat, 15 Nov 2008 18:32:41 -0500
mttc wrote:
As other criticism on Java, Properties is also big missing. Many say
what problem with get or set?
the answer is simple. it's true! the get and set it's good. The
problem is when we use it:
i=s.getX();
s.setX(i);
why Java (after so many years) not able to give us simple code (as
Delphi):
i=s.X;
s.X=i;
The benefit of the latter form is more circumspect. In the three languages that I have experience with where this feature is implemented--PHP, (Mozilla) JavaScript, and python--I have found this to be a barrier to comprehension at least once in each language, often times multiple times.
I don't profess to know all the use-cases for Java programming, but I've never really felt such a feature to be needed. At least in the projects I've mucked around in, writing getters/setters for everything naïvely tends to be frowned upon. The boilerplate it would reduce is small, but then again, most of the same cases can be made against the for-each loop.
If your main reason for proposing feature inclusion is "XXX language has it," I recommend you just drop the idea. Why not include all those nice features that Cobol has, then?
There have many debate and page on the Internet. I say to java Leaders
do what developer ask!
Let's see what developers think. According to <http://www.javapolis.com/confluence/display/JP07/Whiteboard+results+-+Language+change> (the site seems to be down, so I checked the Way Back Machine)... hmm, the information is in images which are presently inaccessible.
Looking around on Google, I get this summary of results (<http://www.jroller.com/scolebourne/entry/voting_on_java_7_language>):
There was some support for Better null handling (with a new operator) and Properties. The balance was slightly against, but not overwhelming.
Recalling from memory, I think there was a fair number of "don't care votes," but don't hold me to that.
So it seems that developers aren't as gung-ho about the feature as you imagine.
I see the Bean-Properties Project, it's seem very poor solution. the
correct way is do it in the lang itself. but Java Guys not going to
confess on this big mistake. therefor we continue wasting time to
search right set or get from long members list. or typing extra dots
and parenthesis (or yield.. ).
I only use IDE autocompletion when I can't remember the name of a method.
Your complaint about having to view too many members in a list doesn't really make sense (you'd have just as many properties as you did getters...), and having to type 5 extra characters (4 for the setter) isn't exactly overwhelming, since that would be less than the average property name.
Java has undeniably bigger mistakes--not making int an object is one (mostly ameliorated via auto-(un)boxing), and the lack of generics reification is another. In both cases, certain tasks become actually impossible without having to throw more stuff around, as opposed to the lack of a properties where the workarounds consist of typing a few more characters.
--
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
.
- Follow-Ups:
- Re: the Java Lang will support Properties in Futuere?
- From: Joshua Cranmer
- Re: the Java Lang will support Properties in Futuere?
- References:
- Prev by Date: Re: the Java Lang will support Properties in Futuere?
- Next by Date: Re: Problem with multiple classes
- Previous by thread: Re: the Java Lang will support Properties in Futuere?
- Next by thread: Re: the Java Lang will support Properties in Futuere?
- Index(es):
Relevant Pages
|
