headers
Alex Tkachman | 25 Jun 17:49

[groovy-dev] defining a field and a property of the same name

http://jira.codehaus.org/browse/GROOVY-2864

Is it really a bug or reasonable behavior? I was going to fix it but
realized that it might be logical because if we allow such things then
there is no clear strategy what to do if field and property defined
with different types.

BTW, it has nothing to do with
http://jira.codehaus.org/browse/GROOVY-2917 - which is bug in Verifier
to be fixed.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Paul King | 26 Jun 01:57

Re: [groovy-dev] defining a field and a property of the same name

Alex Tkachman wrote:
> http://jira.codehaus.org/browse/GROOVY-2864
> 
> Is it really a bug or reasonable behavior? I was going to fix it but
> realized that it might be logical because if we allow such things then
> there is no clear strategy what to do if field and property defined
> with different types.

I don't quite understand Jochen's preference for option 2 in the issue
description. I think option 3 sound like what I would expect. With this
thinking, it is a bug and the fix is to generate an appropriate compiler
error message.

The only tricky case (which might be what Jochen is getting at) is if
we already have a protected field in a parent class and we want to make
it a property in the child class should we just piggy back on the
existing field. I guess that seems reasonable.

Paul.

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

    http://xircles.codehaus.org/manage_email
Permalink | Reply |
headers
Martin C. Martin | 26 Jun 02:02

Re: [groovy-dev] defining a field and a property of the same name

I think what Jochen is getting at is, option 2 gives you some control 
over the field compared to:

class A {
   def foo
}

By defining a field as well, you can give it whatever other modifiers 
you like, and Groovy can say "ok, I'll use that for getFoo() and setFoo()."

So it gives you a little more control without having to resort to 
writing getFoo() and setFoo() yourself.

Best,
Martin

Paul King wrote:
> Alex Tkachman wrote:
>> http://jira.codehaus.org/browse/GROOVY-2864
>>
>> Is it really a bug or reasonable behavior? I was going to fix it but
>> realized that it might be logical because if we allow such things then
>> there is no clear strategy what to do if field and property defined
>> with different types.
> 
> I don't quite understand Jochen's preference for option 2 in the issue
> description. I think option 3 sound like what I would expect. With this
> thinking, it is a bug and the fix is to generate an appropriate compiler
> error message.
>
(Continue reading)

Permalink | Reply |
headers
Paul King | 26 Jun 03:20

Re: [groovy-dev] defining a field and a property of the same name


That makes sense now. Option 2 doesn't seem as elegant as
I would like but I can't think of anything better.

Paul.

Martin C. Martin wrote:
> I think what Jochen is getting at is, option 2 gives you some control 
> over the field compared to:
> 
> class A {
>   def foo
> }
> 
> By defining a field as well, you can give it whatever other modifiers 
> you like, and Groovy can say "ok, I'll use that for getFoo() and setFoo()."
> 
> So it gives you a little more control without having to resort to 
> writing getFoo() and setFoo() yourself.
> 
> Best,
> Martin
> 
> Paul King wrote:
>> Alex Tkachman wrote:
>>> http://jira.codehaus.org/browse/GROOVY-2864
>>>
>>> Is it really a bug or reasonable behavior? I was going to fix it but
>>> realized that it might be logical because if we allow such things then
>>> there is no clear strategy what to do if field and property defined
(Continue reading)

Permalink | Reply |
headers
Alex Tkachman | 26 Jun 09:16

Re: [groovy-dev] defining a field and a property of the same name

I hate to deal with

class A {
    private int foo
    String foo
}

On Thu, Jun 26, 2008 at 5:20 AM, Paul King <paulk@...> wrote:
>
> That makes sense now. Option 2 doesn't seem as elegant as
> I would like but I can't think of anything better.
>
> Paul.
>
> Martin C. Martin wrote:
>>
>> I think what Jochen is getting at is, option 2 gives you some control over
>> the field compared to:
>>
>> class A {
>>  def foo
>>]
 }
>>
>> By defining a field as well, you can give it whatever other modifiers you
>> like, and Groovy can say "ok, I'll use that for getFoo() and setFoo()."
>>
>> So it gives you a little more control without having to resort to writing
>> getFoo() and setFoo() yourself.
>>
(Continue reading)

Permalink | Reply |
headers
Paul King | 26 Jun 09:40

Re: [groovy-dev] defining a field and a property of the same name


I would think that would be an error. Are you saying that
you agree that it should be an error or that it will be
difficult to cover all of the cases?

Cheers, Paul.

Alex Tkachman wrote:
> I hate to deal with
> 
> class A {
>     private int foo
>     String foo
> }
> 
> On Thu, Jun 26, 2008 at 5:20 AM, Paul King <paulk@...> wrote:
>> That makes sense now. Option 2 doesn't seem as elegant as
>> I would like but I can't think of anything better.
>>
>> Paul.
>>
>> Martin C. Martin wrote:
>>> I think what Jochen is getting at is, option 2 gives you some control over
>>> the field compared to:
>>>
>>> class A {
>>>  def foo
>>> ]
>  }
>>> By defining a field as well, you can give it whatever other modifiers you
(Continue reading)

Permalink | Reply |
headers
Alex Tkachman | 26 Jun 10:09

Re: [groovy-dev] defining a field and a property of the same name

I am saying that it would be hard to cover all cases, so I suggest to
keep it as is.

On Thu, Jun 26, 2008 at 11:40 AM, Paul King <paulk@...> wrote:
>
> I would think that would be an error. Are you saying that
> you agree that it should be an error or that it will be
> difficult to cover all of the cases?
>
> Cheers, Paul.
>
> Alex Tkachman wrote:
>>
>> I hate to deal with
>>
>> class A {
>>    private int foo
>>    String foo
>> }
>>
>> On Thu, Jun 26, 2008 at 5:20 AM, Paul King <paulk@...> wrote:
>>>
>>> That makes sense now. Option 2 doesn't seem as elegant as
>>> I would like but I can't think of anything better.
>>>
>>> Paul.
>>>
>>> Martin C. Martin wrote:
>>>>
>>>> I think what Jochen is getting at is, option 2 gives you some control
(Continue reading)

Permalink | Reply |
headers
Russel Winder | 26 Jun 10:12

Re: [groovy-dev] defining a field and a property of the same name

On Thu, 2008-06-26 at 11:16 +0400, Alex Tkachman wrote:
> I hate to deal with
> 
> class A {
>     private int foo
>     String foo
> }

I am confused as to why this is not just a compilation error.  At the
core of this class are two fields of the same name and different types.
Even with:

	class A {
		private int foo
		int foo
	}

it seems like an error to me.

--

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
Permalink | Reply |
headers
Alex Tkachman | 26 Jun 10:30

Re: [groovy-dev] defining a field and a property of the same name

Right now it is compilation error :)

On Thu, Jun 26, 2008 at 12:12 PM, Russel Winder
<russel.winder@...> wrote:
> On Thu, 2008-06-26 at 11:16 +0400, Alex Tkachman wrote:
>> I hate to deal with
>>
>> class A {
>>     private int foo
>>     String foo
>> }
>
> I am confused as to why this is not just a compilation error.  At the
> core of this class are two fields of the same name and different types.
> Even with:
>
>        class A {
>                private int foo
>                int foo
>        }
>
> it seems like an error to me.
>
> --
> Russel.
> ====================================================
> Dr Russel Winder                 Partner
>
> Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road,              f: +44 8700 516 084
(Continue reading)

Permalink | Reply |
headers
Russel Winder | 26 Jun 10:44

Re: [groovy-dev] defining a field and a property of the same name

On Thu, 2008-06-26 at 12:30 +0400, Alex Tkachman wrote:
> Right now it is compilation error :)

Oh good, let's leave it that way.

Why is there a thought that this should be anything other than a
compilation error?

--

-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
Permalink | Reply |
headers
Jochen Theodorou | 26 Jun 11:44

Re: [groovy-dev] defining a field and a property of the same name

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.
(Continue reading)

Permalink | Reply |

Gmane