DISCUSSION: Bean/Data classes

[David Goodenough]

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

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