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 All the best, OC > On 26 Jun 2020, at 15:51, Milles, Eric (TR Tech, Content & Ops) > <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> > Sent: Thursday, June 25, 2020 11:56 PM > To: 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
