Re: "super" object expression for attribute, property, and method call

@promote it more, that Groovy is a drop-in  replacement? : Yes On 26/06/2020 20:56, Jochen Theodorou wrote: On 26.06.20 18:43, MG wrote: [...]> 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 somet

Re: "super" object expression for attribute, property, and method call

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

Re: "super" object expression for attribute, property, and method call

On 26.06.20 18:43, MG wrote: [...]> 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 ? from my experience quite a lot. That is how many advertise the migration

RE: "super" object expression for attribute, property, and method call

> I will proceed with proposed changes to "super.@x" and the error messages. > Those items don't seem controversial. https://github.com/apache/groovy/pull/1291 -Original Message- From: Milles, Eric (TR Tech, Content & Ops) Sent: Friday, June 26, 2020 8:51 AM To: dev@groovy.apache.org

Re: "super" object expression for attribute, property, and method call

Anything but annotations, please, especially if they modify resolution algorithm. — Daniil Ovchinnikov JetBrains > On 26 Jun 2020, at 19:18, MG wrote: > > Hmmm - what about an @Java or @JavaCompatible annotation as the switch that > was already proposed. > That way Java to Groovy could jus

Re: "super" object expression for attribute, property, and method call

Then you would force people to immediately convert a large number of their Java source files to correct Groovy, which I think would put people off. What about introducing an explicit "property access" operator, as a counterpart to the existing field access one ? E.g. this.x / super.x  // Cu

Re: "super" object expression for attribute, property, and method call

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 annot

Re: "super" object expression for attribute, property, and method call

1 (for consistency with this.x as a direct field access) 3 (because there is an actual field in the current class B) 1 (because there is an actual field in the current class A) I find the following most consistent: 1. x should refer to the field of the current class if such field exists to sup

Re: "super" object expression for attribute, property, and method call

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 wrote: > > But that "fallback" to field access is just auto-propertie

Re: "super" object expression for attribute, property, and method call

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

Re: "super" object expression for attribute, property, and method call

Jochen, > On 26 Jun 2020, at 18:14, Jochen Theodorou wrote: > > On 26.06.20 18:02, OCsite wrote: >> >>> On 26 Jun 2020, at 17:46, Daniil Ovchinnikov >>> >> > wrote: when located within "getX()", "isX()" or "setX()" >>> I think the meaning of an expr

Re: "super" object expression for attribute, property, and method call

Jochen, [...] > 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, a

Re: "super" object expression for attribute, property, and method call

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 / @C

Re: "super" object expression for attribute, property, and method call

On 26.06.20 18:02, OCsite wrote: On 26 Jun 2020, at 17:46, Daniil Ovchinnikov 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

Re: "super" object expression for attribute, property, and method call

On 26.06.20 17:52, OCsite wrote: Jochen, On 26 Jun 2020, at 17:33, Jochen 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; }

Re: "super" object expression for attribute, property, and method call

> On 26 Jun 2020, at 17:46, Daniil Ovchinnikov > 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

Re: "super" object expression for attribute, property, and method call

As for a breaking change, could it be perhaps controlled by a switch? Old vs new behaviour? Problem is, this simply can't be solved cleanly without a breaking change — either we keep the current messy and inconsistent approach as-is, or we clean it up, which by definition would make a breaking

Re: "super" object expression for attribute, property, and method call

Jochen, > On 26 Jun 2020, at 17:33, Jochen 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 Ja

Re: "super" object expression for attribute, property, and method call

> when located within "getX()", "isX()" or "setX()" I think the meaning of an expression must not depend on the context. — Daniil Ovchinnikov JetBrains > On 26 Jun 2020, at 18:36, Milles, Eric (TR Tech, Content & Ops) > wrote: > > If we were to change the interpretation of "this" and "super"

RE: "super" object expression for attribute, property, and method call

If we were to change the interpretation of "this" and "super" for property expressions, would it be reasonable to let "x" and "this.x" still mean direct field access when located within "getX()", "isX()" or "setX()"? I do understand the potential for big trouble if "this" handling was changed.

Re: "super" object expression for attribute, property, and method call

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 and would lead to a stack overflow in Groovy as soon as you call the get

Re: "super" object expression for attribute, property, and method call

On 26.06.20 16:34, Milles, Eric (TR Tech, Content & Ops) wrote: Sorry for replying to my own... class A {   def x = 1   def getX() { 2 }   def m() { return x } } print new A().m() // output 1 or 2? If we go by the principle of "when in doubt, do it like Java", the answer is quite clear: 1.

Re: "super" object expression for attribute, property, and method call

On 26.06.20 16:04, OCsite wrote: Hi there, note please that IMO, /this.foo/ definitely should go through the /getFoo/ getter if there's one; that is does not happen currently I regard as a pretty grave bug, for it breaks encapsulation. Compare please e.g. the counter example is always: public

Re: "super" object expression for attribute, property, and method call

On 26.06.20 15:51, Milles, Eric (TR Tech, Content & Ops) wrote: [...] Is there an explicit definition of explicit "this" and "super" qualifiers with regards to fields? Not really, we never got to hammer a nail in this bye Jochen

Re: "super" object expression for attribute, property, and method call

Eric, as for my two object-oriented cents' worth... > On 26 Jun 2020, at 16:34, Milles, Eric (TR Tech, Content & Ops) > wrote: > > Sorry for replying to my own... > > class A { > def x = 1 > def getX() { 2 } > def m() { return x } > } > print new A().m() // output 1 or 2? 2 > class B

RE: "super" object expression for attribute, property, and method call

Sorry for replying to my own... class A { def x = 1 def getX() { 2 } def m() { return x } } print new A().m() // output 1 or 2? class B extends A { def x = 3 def getX() { 4 } def m2() { return x } def m3() { return super.x } } print new B().m3() // output 1 or 2? print new B().m2()

RE: "super" object expression for attribute, property, and method call

Thanks for the additional reference. Also, GROOVY-9596 helps provide some additional context. When considering "this.x" and "super.x" where "x" in both cases is a field or property of the super class, I can understand the desire for consistent handling. When "x" is a member in the current cla

Re: "super" object expression for attribute, property, and method call

Hi there, note please that IMO, this.foo definitely should go through the getFoo getter if there's one; that is does not happen currently I regard as a pretty grave bug, for it breaks encapsulation. Compare please e.g. http://groovy.329449.n5.nabble.com/Inconsistency-properties-are-accessed-as-

RE: "super" object expression for attribute, property, and method call

> which means [super.x] behaves different to this.x Yes, they would be different. I always interpreted this behavior as "references to a class member within the declaring class are direct accesses". For me, "super.x" is not a reference to a member from the declaring class, so MOP is okay/expe