Re: Simple property rules

On 2 Apr 2004, at 08:53, Jon Tirsen wrote:
> jastrachan@... wrote:
>
>> On 2 Apr 2004, at 03:10, Bill Burdick wrote:
>>
>>> Maybe the problem with properties is that Groovy automagically 
>>> defines get and set methods.  What about just not having Groovy 
>>> create get/set methods and using rules like these for behavior of 
>>> field syntax:
>>>
>>> 1) this.field directly accesses field, not the get/set methods (only 
>>> when using 'this')
>>
>>
>> Right now using 'field' or 'this.field' will access the field not the 
>> property.
>>
>>> 2) if there are no get/set methods use the field behaves just like a 
>>> regular Java field
>>> 3) if there is a get method or a set method, use the standard bean 
>>> introspection rules
>>
>>
>> I think today the only way to use the getters/setters is to be 
>> outside of the class. i.e. inside the class 'field' refers to the 
>> field. If you're outside the class foo.field uses the getter/setter 
>> (i.e. the field will be invisible so it'll use the getter/setter 
>> instead).
>>
>>
>>> This lets you make a 'backdoor' if you absoultely need to bypass a 
>>> get/set method by creating alternate methods in a class that  access 
>>> its fields using 'this.x' instead of 'x' (you could even add these 
>>> methods to someone else's code at runtime if you had to).
>>
>>
>> Agreed.
>>
>> Though I confess to really wanting to be able to define simple beans, 
>> easily like this
>>
>> class Customer {
>>     String name
>>     Integer id
>>     Date dob
>>     Address address
>> }
>>
>> without writing reams of getter-setters. Where the above could be 
>> improved is maybe using some syntax sugar to specify specific 
>> getter/setter implementations - like C#'s syntax.
>
>
> Noooooooooo!! 
>
> To be honest, C#'s properties are awful.
> 1) It's almost as verbose.
> Java:
> private Object field;
> public void setField(Object o) {
>  this.field = o;
> }
> public Object getField() {
>  return field;
> }
> C#:
> private object field;
> public object Field {
>  get {
>    return field;
>  }
>  set {
>    field = value;
>  }
> }
> 2) You get the ugly implicit "value" variable.
> 3) You can't have different visibility on a getter and a setter (which 
> means they are actually falling back to getters and setters in their 
> own libraries! God knows why they didn't just fix the language when 
> that happened). They are actually fixing this in Whidbey, which would 
> make it almost *exactly* as verbose as Java's getters and setters.
> 4) Fields and properties behave the same way when it comes to syntax, 
> but are actually quite different in subtle ways. For example when it 
> comes to reflection.
> Bonus) The C# syntax just generates getters and setters under the hood 
> anyway! 
>
> We should take inspiration from other languages but I don't think we 
> should look too much at C#. They must have been in a great hurry when 
> they designed it. It might seem great at first sight because all the 
> features, but when you're actually working with it all day long you 
> realize it's just as awkward to use as Java but the language is much 
> bigger and harder to learn. Oh, and you can't get any good IDEs for it 
> (which is what saves Java).

Point taken :)

On reflection the current rules seem fairly reasonable (if you wanna do 
something clever, write a getter / setter etc) but otherwise the common 
case of writing a property is simple.

James
-------
http://radio.weblogs.com/0112098/