DISCUSSION: Bean/Data classes

[Stephen Colebourne]

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/a_bean_keyword.

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).

Stephen