views:

1100

answers:

16

Syntactic sugar for properties for example in C#:

private int x;

public int X{
    get { return x; }
    set { x = value; }
}

or simply

 public int X{ get; set; }

I am missing verbatim strings in java... @"C:\My Documents\" instead of "C:\\My Documents\\"

Do you agree Java needs more "sugar"? Any one knows is there is sugar coming in next Java versions?

+1  A: 

That is oldschool C#. Nowadays it is

public int X { get; set; }
Matt Briggs
Sorry, I don't code in C# for quiet some time. This is just two things I miss from the old days at school, since Microsoft practically kicked Java out of all the school curriculum.... but that's a different story any way...
João
Microsoft hasn't even come close to equaling java in University curriculum. I know very, very few major universities that use C# honestly.
Simucal
What about major universities that use C# dishonestly? :)
GalacticCowboy
In Portugal all major Universities know have strong connections to Microsoft...
João
It was not "old days @ school" but " C# old school " read ( first C# programmers). I don't quite get this anyways. If X is public, the get/set are kind of already there... why don't just use it : public int X; and call object.x = 1; int a = object.x;
OscarRyz
Oscar: IMHO, if you use public fields the interface gets "compromised". I mean with a property you can change the implementation latter in time (do validation on valid values setter for example), and the old compiled objects that use that property will not need to be recompiled or changed.
João
But, how can you do validations using the { get;set; } construct? For the "Oldschool" is understandable. But I don't get it for the second.
OscarRyz
I am not that much comfortable with C#/.NET, but why should public int X{ get; set; } not generate exactly the same IL code than "oldschool" example? It seems to be the same thing, equivalent. Assuming thats right, one can replace one for the other without breaking anything.
João
I don't like this construct. One should always validate the values in the setters, and quite often you don't want to return the reference to the property value, but a copy or a read-only version, to avoid exposing object internals. Convenient, but dangerous in my opinion.
Bent André Solheim
@Haters:This is just shorthand for what is shown in the question. If you like, you can manually add the backing field in when/if validation is required. If you don't need the backing field, all it is is extra typing for no real reason.
Matt Briggs
Don't mean to be hateful ;)
Bent André Solheim
A: 

Sugar is bad for your teeth. Syntactic sugar is bad for your brain.

Paul Tomblin
but sweet for my eyes and... fingers...
João
Hear hear. Assembly language forever.
mackenir
No, it's good. Automatic properties, for example, mean that when reading code you can see more on the screen at a time and your brain spends less time doing mundane parsing and more time evaluating the meaning of the code.
Joel Coehoorn
joel +1, paul -1.
Vinko Vrsalovic
@Joel -- agreed!
tvanfosson
"Syntactic sugar" can enhance the terseness (tersitude? tersosity?) of the language, which in turn is actually a good thing for your brain.
GalacticCowboy
I taught joel coehorn everything he knows. however, i did not teach him how to be a tool.
"syntactic sugar causes cancer of the semicolon" -- Alan Perlis
bendin
+10  A: 

Sounds like you want Groovy... Apparently properties are on their way, although not in Java 7 (as @erickson helpfully corrected me about in a comment).

Groovy does have nice string sugar.

Dan Vinton
Yes! Java should integrate some of Groovy's features.
Vinko Vrsalovic
Remi Forax and others are working on properties, but it's definitely not a done deal for Java 7. JavaFX properties should help them along though.
erickson
I'm not positive they are out, but I think they are unlikely. Joe Darcy is leading the effort to collect "small" language changes for Java 7, implying that there's not enough time left to settle "large" changes. Check out Alex Miller's Java 7 language clearinghouse: http://tech.puredanger.com/java7
erickson
Agree. Groovy is good for that and lot more.
OscarRyz
A: 

This isn't entirely necessary.

A simple editor macro could work:

prop int x -->

private int x;

public int getX(){
   return x;
}
public void setX(int val){ 
   x = val;
}

Edit: (in response to comments)

How is this any less readable than:

private int x;

public int X{
    get { return x; }
    set { x = value; }
}
chris
yes, in terms of writing it is true... in terms of reading... I am not so sure...
João
Agreed. Code is read many more times than it is written.
Bent André Solheim
In your first example the property is written with two separated methods, in the second there is only one construct, the property, composed by a setter and a getter. More the second can be written in a even more simplified to read way like Matt Briggs pointed out.
João
why don't you just make the attribute public? That's far more readable, simpler ( and awful ) public int x; // that's it!
OscarRyz
public fields causes a leak in the implementation.
Chii
+10  A: 

While I don't necessarily agree with Java's philosophy, I think that adding lots of syntactic sugar to Java would go against its philosophy. Java is supposed to be a very simple, easy to reason about language with few constructs, kind of a lowest common denominator lingua franca in the programming community. It was largely a reaction to the complexity of C++. There is supposed to be very little "magic" in it, beyond what is needed (garbage collection, mostly) to make it a memory-safe language.

If you want more sugar, etc. in a reasonably high-performance, statically typed language, I would say that Java is just the wrong language for you. You're probably better off just using C#, or maybe D.

dsimcha
"Java is supposed to be a very simple", agreed, but there are things in Java that can get messy... why not add "sugar" to make things more enjoyable?
João
because as soon as more sugar is added, unintentional complexity ensues =)
Chii
+8  A: 

"Syntactic sugar causes cancer of the semicolon."

-- Alan Perlis. Epigrams on Programming.

Diomidis Spinellis
Funny but not a real answer. Should I downvote this?... mmhhh I'm tempted... mmmmhh... Naahh I think I would save 1+ of my rep :P
OscarRyz
Thanks! Re: "real answer", others have answered this question quite well.
Diomidis Spinellis
+1  A: 

I've also developed in both Java and C# the last few years, and find C# a superior language with regards to expressiveness and powerful language constructs. The Java language does not undergo the same degree of changes and updates as C#, atleast not at the same pace. I still don't necessarily mean that Java should be drastically updated, but we need a powerful and expressive statically typed language on the Java platform. I think Scala is going to develop into this replacement language, which we Java developers can switch to when ordinary Java does not cut it.

C# is an absolutely fantastic language; probably the "best" statically typed language these days, but Java is still in my opinion a superior platform. I like Java the platform, and I like C# the language.

Bent André Solheim
A: 

One thing Java would do really well to implement is something equivalent to ref and out parameters.

chris
+2  A: 

While properties are nice, they are not java. I seriously think the javabean spec closed that door ages ago. I think there are clearer cases for syntactic sugar that is needed:

  • Use of inner classes due to lack of delegates/closures. Current syntax is from hell.
  • Methods as first-order language constructs, ie method data types.
  • Type inference with generics
  • Run-time presence of generics in reflection API.
  • Events
krosenvold
+2  A: 

If I use java for anything large again, it will be as an output language from another compiler.

Joshua
A: 

As with many, i am stuck to manage application written in Java 1.4 (migration to 1.5 is one the way in many cases). So even if Java 7 or 8 get new feature I will not be able to used them... Anyways syntactic sugar is good, it can help the writing, reading and analysis of code.

João
A: 

I don't like "syntactic sugar" as is mainly because it would be yet another thing to learn and would most likely get abused eventually. I have cursed at the annoyance of making getters and setters myself though so I understand why one would want to make creating those as easy as possible but I'd rather see @Get, @Set and @GetSet annotations than more syntax thingamajiggers to do the job.

Esko
Seem to me a nice idea, Get/Setter annotation could do the trick... as long it lets you change the getter or setter behavior down the line without breaking the object interface.
João
It's not "another thing to learn", because you have to learn the "setVar"/"getVar" pattern anyway.
niXar
+2  A: 

As per Mark Reinhold's talk at Devoxx 2008, property support will not be added to Java in Java 7.

http://hamletdarcy.blogspot.com/2008/12/java-7-update-from-mark-reinhold-at.html

More info on properties in Java 7 ideas here:

http://tech.puredanger.com/java7#property

Alex Miller
A: 

The java platform has adopted a huge amount of programming languages. If you want more syntactic sugar you could use another language like Groovy or (J)Ruby and it will still run on the jvm and work with your other java-libraries. (I even think there is a C# implementation ;)

finpingvin
A: 

I disagree.

Rastislav Komara
A: 

I've written some annotations (and an annotation processor) that helps this quite a bit.

See http://code.google.com/p/javadude/wiki/Annotations

For example:

@Bean(
    properties={
        @Property(name="name", bound=true), // String is default type
        @Property(name="age", type=int.class, bound=true)
    }
)
public class Foo extends FooGen {}

This generates FooGen containing the fields and get/set methods, as well as making them bound (which is optional). There are many other fun things you can do with these as well.

NOTE: I'm doing a few tweaks now that deprecate the various "override" options.

Enjoy,

-- Scott

Scott Stanchfield