And here comes another requirement... ;-)
(But I guess you have a point, IntelliJ's Groovy parsing alas seems
strained as is right now: In our code it sometimes takes up to several
seconds for the right Intellisense formatting to appear, and in some
cases it sticks to incorrectly marking some code part as erronous -
which fortunately can be fixed by commenting out, saving and commenting
in again).
On 26/06/2020 19:44, Daniil Ovchinnikov wrote:
Anything but annotations, please, especially if they modify resolution
algorithm.
—
Daniil Ovchinnikov
JetBrains
On 26 Jun 2020, at 19:18, MG <mg...@arscreat.com> wrote:
Hmmm - what about an @Java or @JavaCompatible annotation as the switch that
was already proposed.
That way Java to Groovy could just annotate all their ported classes (or at
least the ones that misbehave), and things would bve good.
The other way around would also work, of course: @Groovy / @Consistent / ... to
enable the new behavior. That would make it easier for newcomers.
Bad for the code base, of course, since one would have both branches.
But I agree with OC that it is clear we cannot have both: A clear, consistent,
least-surprise this/super logic, and full Java compatibility...
(Alas it oftentimes seems, that as much as one would like to change Groovy in
some regard, and as much discussion is going on, the current state is already
pretty close to optimal, given Groovy's large scope of requirements)
Cheers,
mg
On 26/06/2020 18:09, Jochen Theodorou wrote:
On 26.06.20 17:52, OCsite wrote:
Jochen,
On 26 Jun 2020, at 17:33, Jochen <blackd...@gmx.org
<mailto:blackd...@gmx.org>> wrote:
On 26.06.20 17:21, Jochen Theodorou wrote:
[...]
public class X {
private String foo;
public String getFoo(){ return this.foo; }
public void setFoo(String foo){ this.foo = foo; }
}
This works perfectly fine in Java
Correct me please if I am wrong, but the reason it work in the thing is
that in Java /this.foo/ is something completely different than in Groovy.
the point was about migrating Java code to Groovy though - the reason
why we have many constructs in Groovy we do not really need.
[...]
What if there's a case when someone /would/ want a limited recursion?
def getX() { some_condition?this.x:1 }
That said, an error would be infinitely better than the current behaviour :)
then call a method that does this and do the recursion on that method.
If we call about migrated Java code, where Groovy idioms have been used,
then you will not see "getFoo(){ return this.foo; }" or "private String
foo;", you will see "String foo" and all problems are solved. My concern
is really solely about the migration story, of Java code executed in Groovy.
bye Jochen
