Another point against the file extension approach is the possibility to rewrite only some methods into “proper” Groovy from the original Java code, leaving the rest untouched.
All the best, OC > On 26 Jun 2020, at 18:43, MG <mg...@arscreat.com> wrote: > > But that "fallback" to field access is just auto-properties in Groovy, so I > don't think it is a counter argument to the idea that this.something should > always prefer to use the property something, not sometimes the field. > But, as I said in my last post > (https://lists.apache.org/thread.html/r6014b9bd66c57ed0626002b0d57196d630a380095f79acb74bd8d311%40%3Cdev.groovy.apache.org%3E > - for some reason that was not delivered to me by mail (?)), imho besides > the point, since the real decision is between to clean up & break Java copy & > paste compatibility - or not... > > Btw: I am wondering how many people are actually aware that copy & paste > compatibility of Groovy with regards to Java is one of its feature, and > something that e.g. Kotlin cannot match ? > How many projects actually use Groovy as a full on replacement for Java ? And > how many see it still as "just a script language" ? > And how can we promote that more ? G-) > > Using a different file extension for "Java-comptible-Groovy", like > "*.jgroovy", would of course also work - but then we are back at "Groovy does > not really have a predetermined file extension for its source files"... > > Cheers, > mg > > > On 26/06/2020 18:14, Jochen Theodorou 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. >> >> bye Jochen >
