Remember http://www.javalobby.org/java/forums/t74270.html?start=0? It seems that everybody read and replied on it:-)

Nearly all proposals made (even the one I added my self) have a serious problem: They don’t play well with interfaces.

First I like to define what I mean when I talk about a Property:

A Property is a member where get().equals(get()) and set(x) => get().equals(x).

The java.util.Properties fulfill this condition nicely, as do simple members like names, etc. The Properties-class was actually what got me the idea: As I was faced at work of writing hundreds of getter/setter and member declarations, I took a short-cut and handled this by named attributes. The only thing we lost (besides some CPU-cycles) was type-safety (not a concern in the situation) and the clear binding that allowed refactoring (important then, no issue now). Most of non-trivial get/set are actually interceptors that don’t modify the behaviour from a simple member access. If this is not true you don’t a have Property in the sense of this text.

Why the concept of properties at all? Because it carries important semantics. The user of a property is encouraged to rely on this, this will simplfy code and makes programm more stable if the rule can be checked by an “meta-assert”.

So general advice, if “dynamic” properties will do: Go for it, especially in web-programming where you can spit out String for numbers and dates.

Well, I admit that this is not too satisfying, so here a better solution, but it’ll require a JSR:

The property keyword

The keyword property is somewhat similar in it use as the enum keyword.

property {
int a,
String b,
HashMap m
}
Read the rest of this entry »