> On 26 Jun 2020, at 17:46, Daniil Ovchinnikov > <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.
Note currently it does, actually :) Based on context, in today's Groovy, this.foo might be compiled either as this.getFoo() or as this.@foo — which I argue is wrong and should be cleaned up :) IMO, this.foo should be always compiled as this.getFoo(). If someone wants this.@foo, it is really very easy to write the one small '@'. And it is intention-revealing and makes it the code intuitively understandable, which are very good traits. Alas, by definition, it would be a breaking change :( I don't see a better solution than the aforementioned compiler switch or an annotation or something like that, which is definitely very ugly thing — but perhaps still a bit less ugly than all the other options. All the best, OC >> On 26 Jun 2020, at 18:36, Milles, Eric (TR Tech, Content & Ops) >> <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> >> Sent: Friday, June 26, 2020 10:21 AM >> To: 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 >