field and proeprty access

[Jochen Theodorou]

Hi,

there was a discussion on the def-list about this, but I like to restart
it and come to an conclusion about what to do. Basically we have this
code here:

class A {
   private something = 'foo'

   def getSomething() {
     return 'bar'
   }

   def doit() {
     println something
     println this.something
     println this.@something
     def cl = { something }
     println (cl())
     cl = {this.something}
     println (cl())
     cl = {this.@something}
     println (cl())

     def obj = this

     println obj.something
     println obj.@something
     def cl = { obj.something }
     println (cl())
     cl = {obj.@something}
     println (cl())
   }
}

def a = new A()
a.doit()

Note: this in a closure refers atm to the closure, but this will change
to the declaring instance. so a "this" inside the closure will have the
same value as outside.

What output do you people expect here? Don't use groovy to run it, just
say what you expect and why. The biggest question here is, if
this.something should access the field directly or se the property. If
we use the property, then a typical getter

def getFoo(){
   return this.foo
}

will end in a endless loop. and must be rewritten as

def getFoo(){
   return this.@foo
}

and what about

def getFoo(){
   return foo
}

endless loop too?

The other point is, if a closure should behave the same way as a normal
block of code here or not. Personally I think the closure should behave
ehre the same way as the a normal block of code, what ever this.foo
means then.

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Dierk König]

> class A {
>    private something = 'foo'

do you really want to create a field here
or a property?
 
 def something = 'foo'

>    def getSomething() {
>      return 'bar'
>    }

cheers
Mittie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Dierk Koenig schrieb:
>> class A {
>>    private something = 'foo'

> do you really want to create a field here
> or a property?

a field... but not private... damn ;) That should have been public!

ok, new code:

class A {
   public something = 'foo'

   def getSomething() {
     return 'bar'
   }

   def doit() {
     println something
     println this.something
     println this.@something
     def cl = { something }
     println (cl())
     cl = {this.something}
     println (cl())
     cl = {this.@something}
     println (cl())

     def obj = this

     println obj.something
     println obj.@something
     def cl = { obj.something }
     println (cl())
     cl = {obj.@something}
     println (cl())
   }
}

def a = new A()
a.doit()

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 13:10, Jochen Theodorou wrote:

> What output do you people expect here? Don't use groovy to run it,  
> just say what you expect and why. The biggest question here is, if  
> this.something should access the field directly or se the property.  
> If we use the property, then a typical getter
>
> def getFoo(){
>   return this.foo
> }
>
> will end in a endless loop. and must be rewritten as
>
> def getFoo(){
>   return this.@foo
> }
>
> and what about
>
> def getFoo(){
>   return foo
> }
>
> endless loop too?

I think the semantics of
        this.foo
should be identical to the semantics of
        def that = this
        that.foo
when foo is public.

That being said, the fact that this rule makes getFoo() recurse for  
ever is undesirable behaviour.

The fact that return @foo is not allowed is anomaly which can (I  
think) be removed. I don't think that this causes ambiguities with  
annotations but I'm open to correction on that point.

We have at least three options:

1/ Do nothing and force people to use this.@foo if they want their  
programs to terminate.

2/ Get the compiler to change x to this.@x and this.x to this.@x in  
the body of any method called getX or setX when there is a field  
called x on the class.

3/ Get the compiler to x to this.@x and this.x to this.@x everywhere  
in the class which has a field X.

Before we discuss what to do - can anybody think of other options?

>
> The other point is, if a closure should behave the same way as a  
> normal block of code here or not. Personally I think the closure  
> should behave ehre the same way as the a normal block of code, what  
> ever this.foo means then.


The last time we discussed this my view was that this should refer to  
the Closure instance and not to the enclosing class' instance. I'm  
still of that opinion but I'm happy to accept that the majority view  
last time was the other way round.

This interpretation of this has some slightly odd consequences.  
Resolving this.x uses the enclosing class' MetaClass whilst x uses  
the Closure's MetaClass (which uses the enclosing class's MetaClass  
first but then looks at the field and properties on the Closure if  
the enclosing class cannot resolve the name and then finally uses the  
delegate)

So "this.delegate" may fail whilst "delegate" will always succeed in  
a Closure.

This is a minor quibble and I do not believe that it will cause major  
confusion.

John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:
[...]
> That being said, the fact that this rule makes getFoo() recurse for ever
> is undesirable behaviour.

indeed.

> The fact that return @foo is not allowed is anomaly which can (I think)
> be removed. I don't think that this causes ambiguities with annotations
> but I'm open to correction on that point.

maybe it could for the return, but in general you have conflicts with
annotations.

> We have at least three options:
>
> 1/ Do nothing and force people to use this.@foo if they want their
> programs to terminate.

please note, that:

class A {
   private a
   def getA(){return a}
}

works

class A {
   private a
   def getA(){
    def cl = {a}
    return cl()
   }
}

doesn't. Ok, that is what it is currently... but at last they should
behave the same way! Or not? Anyway, to have mayn ".@"s out there
doesn't give a good feeling.

> 2/ Get the compiler to change x to this.@x and this.x to this.@x in the
> body of any method called getX or setX when there is a field called x on
> the class.

yes, but limiting this to getter/setter doesn't look nice.

> 3/ Get the compiler to x to this.@x and this.x to this.@x everywhere in
> the class which has a field X.

I think that is what the compiler is doing right now... except that it
isn't reflected in Closures.

[...]

> This interpretation of this has some slightly odd consequences.
> Resolving this.x uses the enclosing class' MetaClass whilst x uses the
> Closure's MetaClass (which uses the enclosing class's MetaClass first
> but then looks at the field and properties on the Closure if the
> enclosing class cannot resolve the name and then finally uses the delegate)
>
> So "this.delegate" may fail whilst "delegate" will always succeed in a
> Closure.
>
> This is a minor quibble and I do not believe that it will cause major
> confusion.

well personally I think that nothing of the closure should be accessible
inside the closure. That means no access to owen or delegate from within
the closure, only from outside. And no method calls for the Closure from
within the Closure.. for example toString, equals, hashcode and such.

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 16:19, Jochen Theodorou wrote:

> [...]
>> This interpretation of this has some slightly odd consequences.  
>> Resolving this.x uses the enclosing class' MetaClass whilst x uses  
>> the Closure's MetaClass (which uses the enclosing class's  
>> MetaClass first but then looks at the field and properties on the  
>> Closure if the enclosing class cannot resolve the name and then  
>> finally uses the delegate)
>> So "this.delegate" may fail whilst "delegate" will always succeed  
>> in a Closure.
>> This is a minor quibble and I do not believe that it will cause  
>> major confusion.
>
> well personally I think that nothing of the closure should be  
> accessible inside the closure. That means no access to owen or  
> delegate from within the closure, only from outside. And no method  
> calls for the Closure from within the Closure.. for example

that really doesn't fly. There are real life situations when a  
closure need to set its own delegate. Also things like delegate.x is  
used when the closure needs to force resolution through its own  
delegate. It is occasionally useful to use owner.x too.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 16:19, Jochen Theodorou wrote:

>> 3/ Get the compiler to x to this.@x and this.x to this.@x  
>> everywhere in the class which has a field X.
>
> I think that is what the compiler is doing right now... except that  
> it isn't reflected in Closures.


It's the compiler just generating bytecode that accesses the filed  
directly rather than going via the MetaClass?


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Dierk König]

> well personally I think that nothing of the closure should be accessible
> inside the closure. That means no access to owen or delegate from within
> the closure, only from outside. And no method calls for the Closure from
> within the Closure.. for example toString, equals, hashcode and such.

This would not allow

def c = { closureArg ->
    closureArg.setDelegate(delegate)
}

which may be limiting when constructing functional languages via curry().

cheers
Mittie

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 16:19, Jochen Theodorou wrote:

>> The fact that return @foo is not allowed is anomaly which can (I  
>> think) be removed. I don't think that this causes ambiguities with  
>> annotations but I'm open to correction on that point.
>
> maybe it could for the return, but in general you have conflicts  
> with annotations.


We don't have to use @ as the annotation decorator, of course. I'm  
beginning to think that supporting @x as a field notation is more  
important than using @ as the annotation decorator.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:

>
> On 21 Jun 2006, at 16:19, Jochen Theodorou wrote:
>
>> [...]
>>> This interpretation of this has some slightly odd consequences.
>>> Resolving this.x uses the enclosing class' MetaClass whilst x uses
>>> the Closure's MetaClass (which uses the enclosing class's MetaClass
>>> first but then looks at the field and properties on the Closure if
>>> the enclosing class cannot resolve the name and then finally uses the
>>> delegate)
>>> So "this.delegate" may fail whilst "delegate" will always succeed in
>>> a Closure.
>>> This is a minor quibble and I do not believe that it will cause major
>>> confusion.
>>
>> well personally I think that nothing of the closure should be
>> accessible inside the closure. That means no access to owen or
>> delegate from within the closure, only from outside. And no method
>> calls for the Closure from within the Closure.. for example
>
> that really doesn't fly. There are real life situations when a closure
> need to set its own delegate. Also things like delegate.x is used when
> the closure needs to force resolution through its own delegate. It is
> occasionally useful to use owner.x too.

can you give a bigger example? For owner, if owner means the closure
above it is one thing, but if  you mean here the enclosing class
instance you have "this".

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:

>
> On 21 Jun 2006, at 16:19, Jochen Theodorou wrote:
>
>>> 3/ Get the compiler to x to this.@x and this.x to this.@x everywhere
>>> in the class which has a field X.
>>
>> I think that is what the compiler is doing right now... except that it
>> isn't reflected in Closures.
>
> It's the compiler just generating bytecode that accesses the filed
> directly rather than going via the MetaClass?

yes

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Dierk Koenig schrieb:

>> well personally I think that nothing of the closure should be accessible
>> inside the closure. That means no access to owen or delegate from within
>> the closure, only from outside. And no method calls for the Closure from
>> within the Closure.. for example toString, equals, hashcode and such.
>
> This would not allow
>
> def c = { closureArg ->
>     closureArg.setDelegate(delegate)
> }
>
> which may be limiting when constructing functional languages via curry().

right, that wouldn't be allowed. something like this would work:

def delegate
  def c = { closureArg ->
      closureArg.setDelegate(delegate)
  }
deleagte = c.delegate

ok, that's not nice. But how about a special property? Something like
"this", only for the closure?

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:

>
> On 21 Jun 2006, at 16:19, Jochen Theodorou wrote:
>
>>> The fact that return @foo is not allowed is anomaly which can (I
>>> think) be removed. I don't think that this causes ambiguities with
>>> annotations but I'm open to correction on that point.
>>
>> maybe it could for the return, but in general you have conflicts with
>> annotations.
>
> We don't have to use @ as the annotation decorator, of course. I'm
> beginning to think that supporting @x as a field notation is more
> important than using @ as the annotation decorator.

we then have to find a new syntax for annotations. I don't see the
problem getting much smaller with this.

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 17:05, Jochen Theodorou wrote:

>> that really doesn't fly. There are real life situations when a  
>> closure need to set its own delegate. Also things like delegate.x  
>> is used when the closure needs to force resolution through its own  
>> delegate. It is occasionally useful to use owner.x too.
>
> can you give a bigger example? For owner, if owner means the  
> closure above it is one thing, but if  you mean here the enclosing  
> class instance you have "this".


I have used owner. delegate when I wanted to force name resolution  
through the delegate of the enclosing closure

{
        x.each { ... owner.delegate.y ...}
}

Access to "owner" is nice but probably not vital. acess to delegate  
is *really* important.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 17:09, Jochen Theodorou wrote:

> right, that wouldn't be allowed. something like this would work:
>
> def delegate
>  def c = { closureArg ->
>      closureArg.setDelegate(delegate)
>  }
> deleagte = c.delegate


That's very unpleasant and doesn't cover many of the use cases

  f { closureArg ->
      closureArg.setDelegate(delegate)
  }


I don't really i=understand why you object to this. You do agree that  
the unqualified names used in a closure must be resolved via the  
Closure's MetaClass don't you?


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 17:10, Jochen Theodorou wrote:

> John Wilson schrieb:
>> On 21 Jun 2006, at 16:19, Jochen Theodorou wrote:
>>>> The fact that return @foo is not allowed is anomaly which can (I  
>>>> think) be removed. I don't think that this causes ambiguities  
>>>> with annotations but I'm open to correction on that point.
>>>
>>> maybe it could for the return, but in general you have conflicts  
>>> with annotations.
>> We don't have to use @ as the annotation decorator, of course. I'm  
>> beginning to think that supporting @x as a field notation is more  
>> important than using @ as the annotation decorator.
>
> we then have to find a new syntax for annotations. I don't see the  
> problem getting much smaller with this.

Sorry - i didn't understand that.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:

>
> On 21 Jun 2006, at 17:10, Jochen Theodorou wrote:
>
>> John Wilson schrieb:
>>> On 21 Jun 2006, at 16:19, Jochen Theodorou wrote:
>>>>> The fact that return @foo is not allowed is anomaly which can (I
>>>>> think) be removed. I don't think that this causes ambiguities with
>>>>> annotations but I'm open to correction on that point.
>>>>
>>>> maybe it could for the return, but in general you have conflicts
>>>> with annotations.
>>> We don't have to use @ as the annotation decorator, of course. I'm
>>> beginning to think that supporting @x as a field notation is more
>>> important than using @ as the annotation decorator.
>>
>> we then have to find a new syntax for annotations. I don't see the
>> problem getting much smaller with this.
>
> Sorry - i didn't understand that.

because not before long we need to support annotations. If we want to do
that we need to write that in our files, so we need a syntax for it. I
would really like to see them in Groovy before 1.0 as addition. We may
sovle the .@ problem then when we say annotations will ahva a different
syntax, but we have the problem then for the annotations.

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:

>
> On 21 Jun 2006, at 17:09, Jochen Theodorou wrote:
>
>> right, that wouldn't be allowed. something like this would work:
>>
>> def delegate
>>  def c = { closureArg ->
>>      closureArg.setDelegate(delegate)
>>  }
>> deleagte = c.delegate
>
>
> That's very unpleasant and doesn't cover many of the use cases
>
>  f { closureArg ->
>      closureArg.setDelegate(delegate)
>  }
>
>
> I don't really i=understand why you object to this. You do agree that
> the unqualified names used in a closure must be resolved via the
> Closure's MetaClass don't you?

local variables can't. Fields wouldn't have to. you can't really avoid
that a field is set if it is defined in the outer class instance, or? I
do go up all owners till the end and then make my first try there, or not?

But... the thing I meant with "this" is to have another magic variable
like "it" in a closure, this time refereing to the closure. With that we
can set owner and delegate. Currently we have two "magic" variables,
owner and delegate.

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 18:44, Jochen Theodorou wrote:

>>  }
>> I don't really i=understand why you object to this. You do agree  
>> that the unqualified names used in a closure must be resolved via  
>> the Closure's MetaClass don't you?
>
> local variables can't. Fields wouldn't have to. you can't really  
> avoid that a field is set if it is defined in the outer class  
> instance, or? I do go up all owners till the end and then make my  
> first try there, or not?

Yes local variables do not go via any metaclass

If we decide that this refers to the enclosing class then this.x is  
resolved using the enclosing class' metaclass. All unqualified names  
which are non local variables are resolved via the Closure's metaclass.

The compiler just chooses which metaclass to use the metaclass does  
the rest.

>
> But... the thing I meant with "this" is to have another magic  
> variable like "it" in a closure, this time refereing to the  
> closure. With that we can set owner and delegate. Currently we have  
> two "magic" variables, owner and delegate.

They are not really magic they are real properties on the Closure.  
They are available from inside and outside the Closure.

This stuff isn't really a problem. What we have now works fine. We  
only really have two issues to resolve:

1/ what does this refer to in a closure?

2/ does the compiler systematically change property accesses to field  
accesses in a Closure if the name of the property is the same as the  
name of a filed on the enclosing Class.

I think we are all content that this in a closure refers to the  
enclosing class (so that names are resolved via the enclosing class'  
metaclass).

I don't have a final view on 2.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 21 Jun 2006, at 18:40, Jochen Theodorou wrote:

>> Sorry - i didn't understand that.
>
> because not before long we need to support annotations. If we want  
> to do that we need to write that in our files, so we need a syntax  
> for it. I would really like to see them in Groovy before 1.0 as  
> addition. We may sovle the .@ problem then when we say annotations  
> will ahva a different syntax, but we have the problem then for the  
> annotations.


OK so we could decide not to use @ as the annotation decorator and  
use # instead. Would you be happy with that?


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email