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.
In any case I think the annotation approach is mostly superior.
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
