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
>
