[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-dev
Subject:    Re: [groovy-dev] defining a field and a property of the same name
From:       Jochen Theodorou <blackdrag () gmx ! org>
Date:       2008-06-26 9:44:59
Message-ID: 4863651B.9030906 () gmx ! org
[Download RAW message or body]

Alex Tkachman schrieb:
> I hate to deal with
> 
> class A {
>     private int foo
>     String foo
> }

my main-reason for option two was, that if you have this code:

this.foo =1

then you access the field directly, instead of the property-setter. This 
will align with the property only if a field of the same name as the 
property is used. If not, then this code will all of a sudden call the 
setter instead of putting the value into the field. I see this as 
inconsistent, therefor I don't like it ;)

Fields from a super class are not really a problem, because a subclass 
is allowed to define a field of the same name, even if the field in the 
super class is public. Of course I wouldn't encourage such things.

As in the case above, where the types do not match... For the same 
reason as above I would not like to create two fields here. We could 
make a test like we do with covariants. That means if the field type is 
a of the same class as the property, or of a super class, then we use 
the field, else we throw an compilation error. That does not mean it is 
impossible to use a different type for the getter and setter, it just 
means that Groovy won't support doing such things with the property 
definition syntax and you have to define the methods on your own.

that means:

  class A {
      private int foo
      String foo
  }

should not compile, and

  class A {
      private int foo
      String getFoo(){}
      void setFoo(Exception x){}
  }

should compile, even though the types are all different.

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


[prev in list] [next in list] [prev in thread] [next in thread]