Skip to main content

Language extensions

15 replies [Last post]
ahoma
Offline
Joined: 2003-06-20
Points: 0

I would like to see a continuation of what started with 1.5 Generics.
What I am looking is write code in a clear and short way.

1. Add closures to Java. Yes it is syntactic sugar a lot of people say, but take a look what you can do with Groovy. You can express your algorithm in a lot less lines. The code becames more readable, and in some cases it can be describing an algorithm a lot better.
Closures are nothing more than inner classes that encapsulates a sequance of code.

2. Add properties to Java classes. I see hundreds of setters and getters. We should adopt the C# syntax. Currently I have to write

private int size_;

/**
* @return Returns the size.
*/
public int getSize() {
return size_;
}
/**
* @param size The size to set.
*/
public void setSize(int size) {
size_ = size;
}

All this error prone repetions takes away from the real coding. Yes it is true that todays editors allow generation of this code in no time, but why should this be generated by the editor when the compiler can do it for us. Our java source code will be shorter and more expressive.

Ex:
The compiler can recognize something like this

public property int size;

public read-only property int size;

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
brucechapman
Offline
Joined: 2004-03-18
Points: 0

[code]
abstract class HashCache {
private boolean generated;
private int value;

public int getValue() {
if(! generated) {
value = generate();
generated = true;
}
return value;
}

abstract int generate();
}

public class Test {
private HashCache hashCache = new HashCache() {
int generate() { return calculateHashCode(); }
};

public int hashCode() {
return hashCache.getValue();
}

// can't see the value anywhere in here
}
[/code]

but it still begs the question: Why?

vhi
Offline
Joined: 2004-10-11
Points: 0

One benefit what I can think of, is that a method-level 'static' reduces the clutter in the object space for the cases that Tsinger has mentioned.
But, I do not think that this feature is worth the effort. I personally have not seen much use of the 'static' feature in C++, and where I have seen it, it was a design problem (i.e., monolithic, procedural code and all).

tsinger
Offline
Joined: 2003-06-10
Points: 0

It would be nice, when one could hide the field to the class somehow:
[code]
public class Test {
public int hashCode() {
private int hashCode; /* note the private!*/
if (hashCode == null) {
hashCode = calculateHashCode();
}
return hashCode;
}

public void doSomething() {
if (this.hashCode == 0) { /* compiler-error*/
}
}
}
[/code]

vhi
Offline
Joined: 2004-10-11
Points: 0

I think what you want is akin to the C++ method-level static keyword.

e.g.

void method() {
static int i=0;
...
}

I believe the 'static' keyword to be more intutive, because it clearly indicates that the variable is bound to the method and not to the object. The scope of the variable remains at method-level. A 'private int' might cause confusion among developers because a method-scoped variable is already 'private' to the method, making the 'private' keyword redundant.

Message was edited by: vhi

tuthach
Offline
Joined: 2004-09-17
Points: 0

I definitely agree on this issue with property. Property is not a method, so why should I call a method to get the property? This is very awkward. If I have an int property and Java supports property like C#, I can then do

obj.intProperty++;

instead of:

obj.setIntProperty(obj.getProperty() + 1);

ahoma
Offline
Joined: 2003-06-20
Points: 0

You can only do obj.intProperty++ if intProperty is declared as a field of obj's class.

Yes it may seem semantics, but fields in Java are not the same as properties. Let me remind you that properties had been introduced by the JavaBean specification.

Take a look in chapter 7 of the JavaBean specification document where it says, "Properties are discrete, named attributes of a Java Bean".

tuthach
Offline
Joined: 2004-09-17
Points: 0

I can do that with properties in C# without any problem unless it is a read-only property. I am referring to C# here, not Java.

Yes, it is semantics; we can achieve the same thing by writing code differently like I have shown in my previous example. But some ways are more elegant than others. And of course, fields are different from properties.

I have heard of Java plans to include properties like C# in the next Java version, but who knows when that is and what it will look like by the final release. By the final release, it might be that instead of writing getProperty/setProperty, they will replace it with gProperty/sProperty :). Maybe they should have done this years ago already instead of playing catch up with Microsoft.NET all the time.

> You can only do obj.intProperty++ if intProperty is
> declared as a field of obj's class.
>
> Yes it may seem semantics, but fields in Java are not
> the same as properties. Let me remind you that
> properties had been introduced by the JavaBean
> specification.
>
> Take a look in chapter 7 of the JavaBean
> specification document where it says, "Properties are
> discrete, named attributes of a Java Bean".

monika_krug
Offline
Joined: 2004-10-14
Points: 0

What exactly are closures? Can you give an example?

Monika.

zander
Offline
Joined: 2003-06-13
Points: 0

This one explains closures quite simple.
http://www.artima.com/forums/flat.jsp?forum=121&thread=49705

tsinger
Offline
Joined: 2003-06-10
Points: 0

The example looks interesting, but how you imagine, this could be written in Java 6?

vhi
Offline
Joined: 2004-10-11
Points: 0

I would also like to see the @Property annotation. It really reduces the clutter. Anyway, 70% of the time we have only simple getters and setters.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

As for properties, similar proposal is here:
http://forums.java.net/jive/thread.jspa?threadID=104

What do you think?

ekeeton
Offline
Joined: 2004-10-06
Points: 0

Your suggestion would only cover the simple cases where the getters and setters are directly accessing the underlying instance variable. Granted, this is what probably at least 75% of the code I see does.

In those cases I agree that a property keyword like you suggest would reduce the "clutter". However, you still need some syntax to handle the non-trivial cases, for example where vetting, calculating, or retrieval processing is needed.

I suppose in your suggestion the compiler could supply default getters and setters, similar to a default constructor. So when you wrote:

[b]public property int size;[/b]

you would get (invisibly) something like:

[b]private int size;

public int getSize() {
return size;
}

public void setSize(int size) {
this.size = size;
}

[/b]
This would seem to be consistent with the JavaBean paradigm. And as with constructors, if you didn't like the default, you could write your own.

The example you give is not C# syntax. (I'm not sure that you meant it as such.)

> Ex:
> The compiler can recognize something like this
> [b]
> public property int size;
>
> public read-only property int size;
> [/b]

C# syntax goes like this:
[b]private int size;
public int Size {
get {return size;}
set {size = value;}
}
[/b]
This style might help some in the trivial case of directly accessing the underlying instance variable, but I don't see this as a significant reduction of coding burden for non-trivial getters and setters. And it's more or less an abomination when you do get beyond the non-trivial cases.

Of course you then access these properties like this:

[b]int a = myObject.Size;
[/b] rather than in Java,
[b]int a = myObject.getSize();[/b]

and

[b]myObject.Size = 4;[/b]
rather than
[b]myObject.setSize(4);[/b]

From those I've discussed this with, this is what people who like properties like the most. No matter what's going on behind the scenes, reading a property directly (seemingly) is clearer to some people than reading the result of a method. This seems even more the case with setting a property value versus passing a value to a method.

In my opinion, this style is actually more confusing than Java properties. For example with:
[b] a = myObject.Size;[/b]

I don't know for sure whether I'm reading a property or the instance variable directly. At least not without relying on a pre-determined coding convention. (And on the C# projects I've had to work on, I've already seen several different conventions promulgated as "authoritative".)

And with:

[b]myObject.Size = y;[/b]

I seem to be making a simple assignment, but I have to remember, if I first remember that Size is in fact a property, that there may be side-effects. And now I'm almost all the way back to C++ where I'm never really sure what [b]a=b[/b] does.

(See Graham Hamilton's blog on this.)
http://weblogs.java.net/blog/kgh/archive/2004/09/evolving_the_ja.html

Basically, I think a "property" keyword that triggered default getters and setters would be a good idea. But I would be against using dot notation to read and write properties.

rythos
Offline
Joined: 2004-08-31
Points: 0

I haven't used 5.0 _at all_ yet, so if I'm wrong, that'll be why ;).

Can't you do something similar to this with annotations? Maybe something like

@Property public int size;

This whole property business seems like "boilerplate" code, which is what annotations were designed to reduce.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Yes.
http://forums.java.net/jive/thread.jspa?threadID=104&tstart=0

But that would only solve syntax issue. We still need compiler support for this.