Quite. There is a number of inconsistencies which I would very much like cleaned from Groovy, far as reasonably possible. In my personal opinion probably the worst of them all (though definitely not the only one) is
=== 34 ocs /tmp> <q.groovy class q { private foo='foo ivar' def getFoo() { 'foo getter' } void oops() { def o=this println "although o===this is ${o===this}, '$this.foo' differs from '$o.foo'!" } static main(args) { q.newInstance().oops() } } 35 ocs /tmp> /usr/local/groovy-3.0.4/bin/groovy q although o===this is true, 'foo ivar' differs from 'foo getter'! 36 ocs /tmp> === Thanks and all the best, OC > On 27 Jun 2020, at 16:23, Milles, Eric (TR Tech, Content & Ops) > <eric.mil...@thomsonreuters.com> wrote: > > 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 <mailto:o...@ocs.cz>> > Sent: Saturday, June 27, 2020 6:21 AM > To: dev@groovy.apache.org <mailto:dev@groovy.apache.org>; Paul King > <pa...@asert.com.au <mailto: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 >