Eclipse Xtends Java The Eclipse Foundation has quietly launched a new language, Xtend, which it says is designed to address shortcomings of Java without replacing it. The aim of Xtend is to create more readable code, to add features that Java needs but doesn’t have, and to offer “a convenient alternative in situations where Java doesn’t shine”. …
The main point of Java (outside of Android) is that you have a very picky, explicit, and yes, redundant language where everything is fully spelled out so you can let hordes of incompetent corporate coders work on a project without stepping on each others' toes too much.
Though I guess if you're used to Java and need to run on the JVM there's nothing wrong in moving Java back towards being fun to program with a preprocessor like this, since the enterprisey types can just ignore it. I can see where it'd make Android programming much less tedious.
"It supports direct access to Java properties, allowing a more “natural” statement like person.name=”Foo” to replace person.setName(“Foo”)."
I'm halfway (I hope) through a Java course, in which it's fairly plain that you -can- expose class properties when you write a program but you're advised not to, evidently so that you can change what they are and what actually happens in setName("Foo"). Validating "Foo" as an acceptable name value comes to mind, as does the vast topic of the actual forms that personal names can take. You could have behind it givenName, parentName, nameOrder, ...
Yes, the get/set method syntax is a bit burdensome. But the alternative has its problems, too.
When coding in C# I found myself forced into silly naming conventions to prevent conflict and ambiguity between member field names and property methods. (Made ten times worse by a ridiculous Style Nazi add-on to Visual Studio that used to bitch about naming conventions - probably written by the jerk who did the grammar warnings in MS Word.)
The problem rarely arises when using the public interface to a class. Few experienced coders expose fields these days. But it needs to be clear in member methods whether we're accessing the field or the property.
Given the choice between get/set and having to call fields things like "mName", I think I prefer the former. It's mainly because "getName", "setName" and "name" have a relationship that's clear from reading them, but also because, in my heade at least, "mName" sounds like a cross between "M'Lud" and "My Computer".
Just guessing, but if "name" is a private string, it could assume that thing.name = "abc"means you followed the bean naming convention and replaces .name = "abc" with .setName ( "abc" ).
JSTL does the same with the getter: ${ thing.name } returns "abc" .
If you mispell the getter as getNAme(), and name is private, it won't work
Re the properties access, what it means is that if you would have written a simple setter such as setName(String name) {this.name=name}, instead you just don't need to.
If on the other hand you want to do something more advanced (eg adding validation etc), I *assume* you can write a setName(String name) method like normal. You would still only ever do person.name = "Foo" on the calling side though.
The PlayFramework already does this and once you get your head around the fact that you aren't directly accessing the class's fields even though it feels like you are, it works really well.
It's interesting to note that as a dictatorship, MS has unilaterally added a lot of really nice features to C# without getting stuck in a lot of 'democratic' bickering about the best way to do things and without forcing C# developers into decisions as to which unofficial add-ons to work with.
I'm not a fan of MS and their practices by any means but it does illustrate that there is a downside to the "community" approach to standardization.
Some of the features look nice in principle, but some others are, in my opinion, unnecessary and prone to obscure bugs due to the generated Java code being subtly different from what was expected.
In particular, I *hate* the "new" switch - it looks like a shorthand for consecutive if sentences (and that's probably what it will compile to, anyway), {liberating us from | missing the point of} the fact that a switch statement is supposed to be a shorthand for evaluating a single expression.
And while we're at it, Xtend could add a REPEAT/UNTIL sentence (to {be synonymous with | replace} the do-while one).
And something that would be actually VERY nice would be to add the capability of returning two/three/N objects from a method in a single declaration, instead of having to create a TO for that purpose (or an Object array). Something like this:
public String,boolean,int whatDayIsIt(Date d) {
...
return dayName(d.get(Calendar.DAY_OF_WEEK)), isItHoliday(d), daysUntilChristmas(d);
}
to be used like this:
myDay, holiday, days = whatDayIsIt( new Date());
In the end, what really matters is oldtaku's opinion ("The main point of Java (outside of Android) is that you have a very picky, explicit, and yes, redundant language where everything is fully spelled out so you can let hordes of incompetent corporate coders work on a project without stepping on each others' toes too much."). "Free form" Java wouldn't be good news, I think.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
