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 >> >
