field and proeprty access

classic Classic list List threaded Threaded
35 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Reply | Threaded
Open this post in threaded view
|

RE: field and proeprty access

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

Reply | Threaded
Open this post in threaded view
|

Re: field and proeprty access

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

Reply | Threaded
Open this post in threaded view
|

Re: field and proeprty access

tugwilson
In reply to this post by Jochen Theodorou

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

Reply | Threaded
Open this post in threaded view
|

Re: field and proeprty access

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

Reply | Threaded
Open this post in threaded view
|

Re: field and proeprty access

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

Reply | Threaded
Open this post in threaded view
|

Re: field and proeprty access

tugwilson
In reply to this post by Jochen Theodorou

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

Reply | Threaded
Open this post in threaded view
|

RE: field and proeprty access

Dierk König
In reply to this post by Jochen Theodorou
> 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

Reply | Threaded
Open this post in threaded view
|

Re: field and proeprty access

tugwilson
In reply to this post by Jochen Theodorou

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

Reply | Threaded
Open this post in threaded view
|

Re: field and proeprty access

Jochen Theodorou
In reply to this post by tugwilson
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

1234