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
