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

ath. > VariableScopeVisitor handles matching variable expressions to members. > StaticTypeCheckingVisitor and AsmCLassGenerator perform additional checking > and resolution. > > From: OCsite mailto:o...@ocs.cz>> > Sent: Saturday, June 27, 2020 6:21 AM > To: dev@gr

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

; was more clear, but I am quite concerned that any change in > the property handling could be a breaking change for someone's code base. > > -Original Message- > From: Jochen Theodorou mailto:blackd...@gmx.org>> > Sent: Friday, June 26, 2020 10:21 AM > To: de

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

Mg, > On 26 Jun 2020, at 19:29, MG wrote: > > 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 as

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

gt; I thought "super" was more clear, but I am quite concerned that any change > > in the property handling could be a breaking change for someone's code base. > > > > -Original Message- > > From: Jochen Theodorou mailto:blackd...@gmx.org>>

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

; or > "setX()"? I do understand the potential for big trouble if "this" handling > was changed. I thought "super" was more clear, but I am quite concerned > that any change in the property handling could be a breaking change for > someone's code

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

To: dev@groovy.apache.org Subject: 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 dec

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

int new B().m() // output 1 or 2 or 3 or 4? > > > From: Milles, Eric (TR Tech, Content & Ops) > Sent: Friday, June 26, 2020 9:25 AM > To: dev@groovy.apache.org > Subject: RE: "super" object expression for attribute, property, and method > call >

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

. I >> thought "super" was more clear, but I am quite concerned that any change in >> the property handling could be a breaking change for someone's code base. >> >> -Original Message- >> From: Jochen Theodorou >> Sent: Friday, Jun

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

ng change for someone's code base. > > -Original Message----- > From: Jochen Theodorou > Sent: Friday, June 26, 2020 10:21 AM > To: dev@groovy.apache.org > Subject: Re: "super" object expression for attribute, property, and method > call > > On

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

t; understand the potential for big trouble if "this" handling was changed. I > thought "super" was more clear, but I am quite concerned that any change in > the property handling could be a breaking change for someone's code base. > > -Original Message----

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

ou Sent: Friday, June 26, 2020 10:21 AM To: dev@groovy.apache.org Subject: 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/ ge

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

Milles, Eric (TR Tech, Content & Ops) > Sent: Friday, June 26, 2020 9:25 AM > To: dev@groovy.apache.org > Subject: RE: "super" object expression for attribute, property, and method > call > > Thanks for the additional reference. Also, GROOVY-9596 helps provide som

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

() // output 3 or 4? print new B().m() // output 1 or 2 or 3 or 4? From: Milles, Eric (TR Tech, Content & Ops) Sent: Friday, June 26, 2020 9:25 AM To: dev@groovy.apache.org Subject: RE: "super" object expression for attribute, property, and method call Thanks for the additional re

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

tX() { 3 } } new B().m() // as discussed in nabble link, should this return 1 always or 2 or 3? From: OCsite Sent: Friday, June 26, 2020 9:05 AM To: dev@groovy.apache.org Subject: Re: "super" object expression for attribute, property, and method call Hi there, note please that IMO,

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

> fully understand what can be expected when using the super qualifier. > > > I will proceed with proposed changes to "super.@x" and the error messages. > Those items don't seem controversial. > > > -Original Message- > From: Jochen Theodo

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

---Original Message- From: Jochen Theodorou Sent: Thursday, June 25, 2020 11:56 PM To: dev@groovy.apache.org Subject: Re: "super" object expression for attribute, property, and method call On 25.06.20 23:34, Milles, Eric (TR Tech, Content & Ops) wrote: > The handling for "

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

On 25.06.20 23:34, Milles, Eric (TR Tech, Content & Ops) wrote: The handling for "this" and "super" are separate enough that we could support different behaviors. I think I am looking to make 2 changes to start with: 1) super.@x cannot access a private field and does not try getX(), isX() or a

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

ove the consistency of errors and remove workarounds that IMO go against the spirit of ".@" operator. -Original Message- From: Jochen Theodorou Sent: Thursday, June 25, 2020 3:55 PM To: dev@groovy.apache.org Subject: Re: "super" object expression for attribute, prop

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

On 25.06.20 18:05, Milles, Eric (TR Tech, Content & Ops) wrote: I've been looking into GROOVY-8999 since I have a better understanding of where some of the unexpected error messages come from.  What exactly is the expectation for use of super qualifier in terms of accessible and inaccessible memb

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

I've been looking into GROOVY-8999 since I have a better understanding of where some of the unexpected error messages come from. What exactly is the expectation for use of super qualifier in terms of accessible and inaccessible members? It is strange that I can safely call "new A().@x" anywher