It depends on what you mean by context. Currently, this.x means field
access within the class and property access outside the class. I agree, I
wouldn't like to see "within the class" further split into specific methods
like getters, setters, constructors but not elsewhere. We already have
mechanisms in place with some AST transforms (@Builder, @TupleConstructor)
to allow using setters in some circumstances.
Cheers, Paul.
On Sat, Jun 27, 2020 at 1:46 AM 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.
>
> —
>
> Daniil Ovchinnikov
> JetBrains
>
> > 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
>
>
