Eric, as for my two object-oriented cents' worth...
> On 26 Jun 2020, at 16:34, Milles, Eric (TR Tech, Content & Ops) > <eric.mil...@thomsonreuters.com> wrote: > > Sorry for replying to my own... > > class A { > def x = 1 > def getX() { 2 } > def m() { return x } > } > print new A().m() // output 1 or 2? 2 > class B extends A { > def x = 3 > def getX() { 4 } > def m2() { return x } > def m3() { return super.x } > } > print new B().m3() // output 1 or 2? 2 > print new B().m2() // output 3 or 4? 4 > print new B().m() // output 1 or 2 or 3 or 4? 4 In my personal opinion, “(this).x” should consistently mean precisely the same as “(this.)getX()” — the former should be considered as a pure syntactical sugar over the latter, nothing more, nothing less. Same for the setter. Almost precisely the same for “super”, with the only difference that the implementation search begins in the superclass of the one which calls “super”, instead of in “this” as normally. If someone really needs direct access to the instance variable (I believe the javaspeak of which is “field”), which should never happen outside of the very accessors anyway, there's always .@ to be used explicitly. Something like “def getX() {x+1}” is, in my personal opinion, a grave programmer's bug, precisely same as “def foo() {foo()+1}”, and if someone does that, serves him darn well right :) All the best, OC > > > From: Milles, Eric (TR Tech, Content & Ops) <eric.mil...@thomsonreuters.com> > Sent: Friday, June 26, 2020 9:25 AM > To: dev@groovy.apache.org > Subject: RE: "super" object expression for attribute, property, and method > call > > Thanks for the additional reference. Also, GROOVY-9596 helps provide some > additional context. > > When considering "this.x" and "super.x" where "x" in both cases is a field or > property of the super class, I can understand the desire for consistent > handling. When "x" is a member in the current class, direct field access > seems intuitive to me; OC raises some concern. When "x" is a member of the > current class and a subclass, things start to get complicated. > > class A { > def x = 1 > def m() { x } > } > class B extends A { > def x = 2 > def getX() { 3 } > } > new B().m() // as discussed in nabble link, should this return 1 always or 2 > or 3? > > > From: OCsite <o...@ocs.cz> > Sent: Friday, June 26, 2020 9:05 AM > To: dev@groovy.apache.org > Subject: Re: "super" object expression for attribute, property, and method > call > > 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. > > http://groovy.329449.n5.nabble.com/Inconsistency-properties-are-accessed-as-fields-within-class-td5721135.html > > <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgroovy.329449.n5.nabble.com%2FInconsistency-properties-are-accessed-as-fields-within-class-td5721135.html&data=02%7C01%7Ceric.milles%40thomsonreuters.com%7Cf84f4b6a6db34bd46c1508d819dcb9a2%7C62ccb8646a1a4b5d8e1c397dec1a8258%7C0%7C0%7C637287783081743441&sdata=v4E1B6bsDIU1SqEdVZByJwatBYe%2B0r1Azee6qEWsIC4%3D&reserved=0> > > All the best, > OC > > > On 26 Jun 2020, at 15:51, Milles, Eric (TR Tech, Content & Ops) > <eric.mil...@thomsonreuters.com <mailto:eric.mil...@thomsonreuters.com>> > wrote: > > which means [super.x] behaves different to this.x > > Yes, they would be different. I always interpreted this behavior as > "references to a class member within the declaring class are direct > accesses". For me, "super.x" is not a reference to a member from the > declaring class, so MOP is okay/expected. Indeed, there are bugs cited that > expect "super.x" to drive getX() or isX() in the parent class. > > Is there an explicit definition of explicit "this" and "super" qualifiers > with regards to fields? I'm going off intuition and experience. GROOVY-8999 > tries to show that there is not consistent behavior and so it is hard to > fully understand what can be expected when using the super qualifier. > > > I will proceed with proposed changes to "super.@x" and the error messages. > Those items don't seem controversial. > > > -----Original Message----- > From: Jochen Theodorou <blackd...@gmx.org <mailto:blackd...@gmx.org>> > Sent: Thursday, June 25, 2020 11:56 PM > To: dev@groovy.apache.org <mailto:dev@groovy.apache.org> > Subject: Re: "super" object expression for attribute, property, and method > call > > On 25.06.20 23:34, Milles, Eric (TR Tech, Content & Ops) wrote: > > The handling for "this" and "super" are separate enough that we could support > different behaviors. I think I am looking to make 2 changes to start with: > > 1) super.@x cannot access a private field and does not try getX(), isX() or > any other alternatives. STC should produce an error for this case. > Currently, if the field is not accessible, "super.getX()" is substituted and > so errors for "no getX() method" can be confusing. > > 2) super.x does not bypass accessor methods. So getX() if it exists, isX() > if its boolean, field if field is accessible and no accessor exists, and > finally propertyMissing/MissingPropertyException. > > As you stated below, #1 is a breaking change. Today an inaccessible super.@x > produces a super.getX() substitution. And I think #2 is a refinement; if > user wants to bypass the accessor method, super.@x is and has been available. > > which means it behaves different to this.x > > > I suppose the third change is that when "super.x" fails, the compiler says > "No such property x for B" when A is really the start of the search. Fixing > the error messages would also be beneficial. > > +1 > > > I'm not proposing to enable access to private fields, just improve the > consistency of errors and remove workarounds that IMO go against the spirit > of ".@" operator. > > this has been a story in the past for dynamic Groovy, which is why I > mentioned it explicitly > > bye Jochen >