groovy

Property access works differently depending on whether using "this" or other reference even if they point to the same object

Details

  • Type: Sub-task Sub-task
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.0
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Groovy Version: 1.0 JVM: 1.5.0_10-b03
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

See the attached test case

Issue Links

is depended upon by

Task - A task that needs to be done. GROOVY-2503 MOP 2.0 design inflluencing issues

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andres Almiray added a comment -

The bug is still around

class Foo {
  def aproperty
  def getAproperty() { this.@aproperty ? this.@aproperty : 'a default value' } 

  def test(){
     def other = this
     assert other.@aproperty == this.@aproperty
     assert other.aproperty == "a default value"
     assert this.aproperty == null // ???
     // thw folowing line fails
     assert other.aproperty == this.aproperty
  }
}

def foo = new Foo()
foo.test()

What's weird about this is that is seems there may be an optimization while accessing properties with 'this' as it yields the filed vlaue right away, but with 'other' it follows the long path.

Show
Andres Almiray added a comment - The bug is still around class Foo { def aproperty def getAproperty() { this .@aproperty ? this .@aproperty : 'a default value' } def test(){ def other = this assert other.@aproperty == this .@aproperty assert other.aproperty == "a default value" assert this .aproperty == null // ??? // thw folowing line fails assert other.aproperty == this .aproperty } } def foo = new Foo() foo.test() What's weird about this is that is seems there may be an optimization while accessing properties with 'this' as it yields the filed vlaue right away, but with 'other' it follows the long path.
Hide
Permalink
Antti Karanta added a comment -

I'm under the impression that this is actually by design to make things more familiar to a Java programmer; I recall it is described this way in GinA book. IMO, though, it is a design mistake as it makes the language inconsistent.

Show
Antti Karanta added a comment - I'm under the impression that this is actually by design to make things more familiar to a Java programmer; I recall it is described this way in GinA book. IMO, though, it is a design mistake as it makes the language inconsistent.
Hide
Permalink
Andres Almiray added a comment -

I believe this issue is related to GROOVY-1569

Show
Andres Almiray added a comment - I believe this issue is related to GROOVY-1569
Hide
Permalink
blackdrag blackdrag added a comment -

The issues are not really related, because GROOVY-1569 is about the dynamic scoping once you hit a closure and this here is more about calls from inside a class and from outside a class. Of course the other issue is about this as well, but that is not the sole part there, while it is here. So, what could be doe to make this behave more as you might expect? For example we could check if "other" is the same class as "this" and then use the same access mechanisms... hmm.. no, I think that won't work if I think about subclasses... So what we really would have to do would be to check if "other" is an instance of Foo and then access the field Foo#aproperty directly, instead of going through the getter. Which means this makes this the same problem as with typical equals code, that checks private fields. After this change other.aproperty would return null.

The other way would be to go through the getter all the time, but we decided to not to do this or else poeple will always have to write this.@aproperty when they want to access the field from the current class.

Show
blackdrag blackdrag added a comment - The issues are not really related, because GROOVY-1569 is about the dynamic scoping once you hit a closure and this here is more about calls from inside a class and from outside a class. Of course the other issue is about this as well, but that is not the sole part there, while it is here. So, what could be doe to make this behave more as you might expect? For example we could check if "other" is the same class as "this" and then use the same access mechanisms... hmm.. no, I think that won't work if I think about subclasses... So what we really would have to do would be to check if "other" is an instance of Foo and then access the field Foo#aproperty directly, instead of going through the getter. Which means this makes this the same problem as with typical equals code, that checks private fields. After this change other.aproperty would return null. The other way would be to go through the getter all the time, but we decided to not to do this or else poeple will always have to write this.@aproperty when they want to access the field from the current class.
Hide
Permalink
Antti Karanta added a comment -

IMO checking whether "other" is an instance of Foo and acting on that will cause very confusing behavior, so that idea can be discarded.

Also, IMO it would be much more consistent to go through the setter all the time and use @property when one really wants to access the instance variable. I realize that this is a major change and would probably break a lot of existing code so it might not be doable.

It could also be that it's just me who finds it confusing that o.property goes via getter, but this.property does not. Well, now that I know it it's not confusing any more, just annoying. And inconsistent - if a language feature has to be described "XXX works such that YYY except when ZZZ it does WTF" it should be seriously reconsidered.
But like I said, it may be too late to change this any more.

Show
Antti Karanta added a comment - IMO checking whether "other" is an instance of Foo and acting on that will cause very confusing behavior, so that idea can be discarded. Also, IMO it would be much more consistent to go through the setter all the time and use @property when one really wants to access the instance variable. I realize that this is a major change and would probably break a lot of existing code so it might not be doable. It could also be that it's just me who finds it confusing that o.property goes via getter, but this.property does not. Well, now that I know it it's not confusing any more, just annoying. And inconsistent - if a language feature has to be described "XXX works such that YYY except when ZZZ it does WTF" it should be seriously reconsidered. But like I said, it may be too late to change this any more.
Hide
Permalink
Luke Daley added a comment -

This really does seem like a bug.

Is fixing this going to be targeted for 2.0?

Show
Luke Daley added a comment - This really does seem like a bug. Is fixing this going to be targeted for 2.0?

People

  • Assignee:
    Unassigned
    Reporter:
    Antti Karanta
Vote (3)
Watch (3)

Dates

  • Created:
    Updated: