As for a breaking change, could it be perhaps controlled by a switch? Old vs
new behaviour?
Problem is, this simply can't be solved cleanly without a breaking change —
either we keep the current messy and inconsistent approach as-is, or we clean
it up, which by definition would make a breaking change.
(Even if this.foo automatically falls back to this.@foo inside a getFoo, still
the change could break some legacy code, which never assumed that “def bar() {
this.foo }” would call getFoo, and thus can be broken if this happens.)
All the best,
OC
> On 26 Jun 2020, at 17: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
