Paul,
> On 27 Jun 2020, at 12:33, Paul King <pa...@asert.com.au> wrote:
> It depends on what you mean by context. Currently, this.x means field access
> within the class and property access outside the class.
It is even more complex that that. If there's no instance variable, it still
falls back to the getter. And it is inconsistent even betwixt static and
instance methods:
===
26 ocs /tmp> <q.groovy
class q {
def getFoo() { 'foo getter' }
private bar='bar ivar',bax='bax ivar'
def getBar() { 'bar getter' }
void instance() {
println this.foo
println this.bar
println this.bax
}
static main(args) {
def o=q.newInstance()
println o.foo
println o.bar
println o.bax
o.instance()
}
}
27 ocs /tmp> /usr/local/groovy-3.0.4/bin/groovy q
foo getter
bar getter
bax ivar
foo getter
bar ivar
bax ivar
28 ocs /tmp>
===
And soon as you inherit, it gets even worse. This is, in my eye, one extremely
ugly mess which, if reasonably possible, definitely should be done with, making
the future behaviour clean, intuitive, readable and intention-revealing,
without surprises of this kind.
All the best,
OC
> 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 <mailto: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 <mailto: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 <mailto:blackd...@gmx.org>>
> > Sent: Friday, June 26, 2020 10:21 AM
> > To: dev@groovy.apache.org <mailto: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
>
