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
