> On 26 Jun 2020, at 17:46, Daniil Ovchinnikov
> <daniil.ovchinni...@jetbrains.com> wrote:
>> when located within "getX()", "isX()" or "setX()"
> I think the meaning of an expression must not depend on the context.
Note currently it does, actually :) Based on context, in today's Groovy,
this.foo might be compiled either as this.getFoo() or as this.@foo — which I
argue is wrong and should be cleaned up :) IMO, this.foo should be always
compiled as this.getFoo(). If someone wants this.@foo, it is really very easy
to write the one small '@'. And it is intention-revealing and makes it the code
intuitively understandable, which are very good traits.
Alas, by definition, it would be a breaking change :( I don't see a better
solution than the aforementioned compiler switch or an annotation or something
like that, which is definitely very ugly thing — but perhaps still a bit less
ugly than all the other options.
All the best,
OC
>> On 26 Jun 2020, at 18:36, Milles, Eric (TR Tech, Content & Ops)
>> <eric.mil...@thomsonreuters.com> wrote:
>>
>> If we were to change the interpretation of "this" and "super" for property
>> expressions, would it be reasonable to let "x" and "this.x" still mean
>> direct field access when located within "getX()", "isX()" or "setX()"? I do
>> understand the potential for big trouble if "this" handling was changed. I
>> thought "super" was more clear, but I am quite concerned that any change in
>> the property handling could be a breaking change for someone's code base.
>>
>> -----Original Message-----
>> From: Jochen Theodorou <blackd...@gmx.org>
>> Sent: Friday, June 26, 2020 10:21 AM
>> To: dev@groovy.apache.org
>> Subject: Re: "super" object expression for attribute, property, and method
>> call
>>
>> On 26.06.20 16:04, OCsite wrote:
>>> Hi there,
>>>
>>> note please that IMO, /this.foo/ definitely should go through the
>>> /getFoo/ getter if there's one; that is does not happen currently I
>>> regard as a pretty grave bug, for it breaks encapsulation. Compare
>>> please e.g.
>>
>> the counter example is always:
>>
>> public class X {
>> private String foo;
>> public String getFoo(){ return this.foo; }
>> public void setFoo(String foo){ this.foo = foo; } }
>>
>> This works perfectly fine in Java and would lead to a stack overflow in
>> Groovy as soon as you call the getter or setter. Since it is quite common we
>> have a problem here.
>>
>> bye Jochen
>
