Jochen, > On 26 Jun 2020, at 18:14, Jochen Theodorou <blackd...@gmx.org> wrote: > > On 26.06.20 18:02, OCsite wrote: >> >>> On 26 Jun 2020, at 17:46, 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. >> >> 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. > > But that is not how property access in general works in Groovy. if you > have foo.bar, then (not considering the specialities of the MOP) this > calls getBar(), but only if getBar() exists. if there is an accessible > (not Java accessible) field bar, then we access the field. If we go > strictly by foo.bar means foo.getBar(), it would mean the call must fail > if there is no getter for bar.
Quite. Myself, I would very strongly prefer that to the current behaviour. As I wrote before, in my opinion it would be best if this.foo is solely a syntactic sugar over this.getFoo(); nothing else. If someone wants this.@foo, he should write that explicitly. On the other hand, the problem with compiling a Java code cannot be overlooked. Perhaps we could compile this.foo to this.@foo only on lines which are terminated by a semicolon :P Jokes aside, no, I do not see a good solution. Best (more precisely least ugly, for ugly as hell it still is) seems to me the aforementioned compiler switch/annotation one, which would allow the programmer to ask for the old behaviour for Java legacy code, and embrace the clean new one for Groovy-written parts. All the best, OC
