Mg, > On 26 Jun 2020, at 19:29, MG <mg...@arscreat.com> wrote: > > Hmmm, yea, in theory - but if you do that I think you are putting yourself in > a whole lot of pain anyway, since not keeping copy & pasted legacy Java code > clearely seperate from true Groovy code, and only ever converting whole > classes, is asking for trouble anyway.
Been there, done that. In my experience, this is the least-painful approach available. Keeping the Groovy and Java code in separate sources would get considerably more difficult and error-prone, especially since neither Java nor Groovy, alas, support splitting an implementation of one big class in more sources, like Objective C categories do. (Lately traits came pretty close, but they still are not quite there.) > In any case I think the annotation approach is mostly superior. Absolutely, +1 on that. All the best, OC > > On 26/06/2020 18:48, OCsite wrote: >> 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 >
