It is this inconsistency that prompted me to open GROOVY-8999. I'm trying to straighten this out cautiously. I thought the "super" qualifier was a reasonable place to start as it has limited application. Changing the behavior of "this" and "implicit-this" is quite a large undertaking. It may be possible to change one or two specific cases, but to switch the field vs. accessor/MOP would require a lot of study and testing.
There is definitely the notion of "static" and "non-static" contexts in the code. Also "within a closure" opens up a different resolution path. VariableScopeVisitor handles matching variable expressions to members. StaticTypeCheckingVisitor and AsmCLassGenerator perform additional checking and resolution. From: OCsite <o...@ocs.cz> Sent: Saturday, June 27, 2020 6:21 AM To: dev@groovy.apache.org; Paul King <pa...@asert.com.au> Subject: Re: "super" object expression for attribute, property, and method call Paul, On 27 Jun 2020, at 12:33, Paul King <pa...@asert.com.au<mailto: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
