DISCUSSION: Bean/Data classes (original) (raw)

David Goodenough david.goodenough at linkchoose.co.uk
Thu Mar 26 09:50:23 PDT 2009

On Wednesday 25 March 2009, Stephen Colebourne wrote:

Reinier Zwitserloot wrote: > You should move away from the idea of 'this keyword does so much > magic!' and move towards the idea that this keyword simply declares > that the class is to have bean semantics.

I proposed almost exactly this 'data' class two years ago - http://www.jroller.com/scolebourne/entry/abeankeyword. public bean Person { // properties property String forename; property String surname; // normal fields and methods private String ordinaryField; public boolean validate() { ... } } This is fundamentally no different to how enum was slotted into the language (note I deliberately omitted the 'class' keyword. The key aspect of this approach is that it allows there to be different grammer rules within 'bean' classes to normal classes, just as there are different rules for 'enum' classes. Now, as for what exactly it generates, that is a much bigger question. Does it just generate getter/setter? What about lists, maps and arrays? How about events? The truth is that is where every property proposal gets bogged down (because server side JavaBeans are just data holders, whereas swing JavaBeans are much more a part of the application). So, will this be in Coin? No. There is way to much to work out. But this could be the best way to get a form of properties into Java. And a group could form to code up a prototype and prove it (Kijaro is available...) Finally, I should say that of all the things Java lacks, I think properties is the biggest - bigger than closures. The sheer amount of wasted effort, lines of code, lack of consistency and sheer focus on the low level detail rather than the high level abstraction is staggering. It is IMO a far bigger hole in writing good Java apps today than closures (or any other language proposal).

Well (given my lightweight Property proposal) I have to say that I agree with this last paragraph. Maybe I have expressed the need for it badly but to me it is blindingly obvious that this is needed, and that it is a gaping hole in Java's otherwise excellent compiler/IDE checkability record. It is nice to know that I am not completely alone in thinking this.

David

Stephen

More information about the coin-dev mailing list