jastrachan | 13 Apr 19:13 2004

Re: Properties

On 13 Apr 2004, at 00:08, Hallvard Trætteberg wrote:
> Hi,
> After a long Easter vacation I come back to a long (and interesting)
> discussion about property support in groovy. It seems there is (enough)
> consensus that groovy should have a shorthand for defining fields with
> getters and setters, and that the dot "." should access properties 
> using
> the available getter.
> Bill Burdick suggested the following rules:
> 1) "this.prop" always accesses the field itself (bypassing any
> setters/getters)
> 2) "property type a" (type is optional) creates the field and a default
> getter and setter
> 3) any getter/setter methods you supply override defaults
> 4) magic dot uses the getter/setter method if they exists, otherwise
> uses the field

Maybe we could merge 1 and 4 together to say....

dot will use the field if you have access to see it, otherwise it will 
use the getter/setter method.

Typically when calling foo.bar you are outside of the declaration of 
the class of foo and so cannot see the field 'bar' and can only see the 
property getter/setter.

> From reading the discussion, it seems there is consensus for 2 and 4,
> but some disagreement on 4 (and little discussion about 1). I think we
> should go for these rules, and continue discussion what extensions to
> this that will make life even more groovy.
> One natural extension to this is adding modifiers for indexed
> properties, e.g.
> class Person {
> 	indexed property String name;
> }

Though you could argue for things like bound / unbound properties and 
readonly or writeonly properties too. This is the slipperly slope thats 
made me consider adding macros to groovy...

> will generate getter and setter methods with an index parameter:
> String getName(int) and void setName(int, String), in addition to
> String[] getNames and setNames(String[]).
> How do you access indexed properties? The natural way is 
> person.name[4],
> but does this first invoke getName() and then index into the array, or
> use getName(int)?

If getNames() returns an Object[] or a Collection of some kind then 
you'd have access to indexed properties via normal subscript operations



> A variant would be to use Lists instead of arrays, and support
> add/remove methods, e.g.
> class Person {
> 	list property String name;
> }
> will generate getter and setter methods with and index parameter:
> String getName(int) and void setName(int, String), add/remove methods
> void addName(int, String) and removeName(int) (and possibly
> addName(String)), in addition to
> List getNames and setNames(List).

FWIW in Zen - which I like alot - you'd do this va

String* names

which means 0..n names or use this

String+ names

for 1..N names

> Another orthogonal extension is support for bound properties, e.g.
> class Person {
> 	bound property String name;
> }
> will generate code for notifying listeners, by both ensuring that the
> class includes support for adding/removing listeners and firing
> PropertyChangeEvents, and that each set method actually fires the 
> event.
> The exact code for doing this may of course be discussed, but I think 
> it
> should be possible to decide on a straight-forward implementation that
> should cover the standard case, and let variants be coded manually,
> without the "bound" modifier.


Though I can imagine folks thinking up new modifiers like

class Pizza {
     readonly lazy property cheese { return new Cheddar }

which creates a lazily-created property