[groovy-jsr] Proposed rules for name resolution

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

[groovy-jsr] Proposed rules for name resolution

tugwilson
All names are resolved in exactly the same way as in Java with the  
following additions and exceptions:

Additions

1/ Closures have names resolved first against any local variables in  
scope at the point of use, second against any visible methods or  
fields on the Closure object (these may be artificially limited so  
that the closure doesn't see irrelevant methods and fields on the  
Closure) third against any enclosing closure's local variables in  
scope at the point of use (and so on out if there are multiple  
enclosing closures), finally against the methods and fields of the  
enclosing class (or against the local variables and the Binding if in  
a script)

2/ Code in a Script resolves the name against local variables at the  
point of use and then against the Binding.

3/ Names which cannot be resolved at compile time will cause an  
exception to be thrown if an attempt is made to access it at run time.

Exceptions:

1/ There are certain extremely obscure situations in which a private  
item cannot be accessed on an object from within an object of the  
same type.


That's it!

Any of this behaviour can, of course, be modified with a custom  
metaclass and some of the behaviour can be modified using the methods  
on Groovy Object


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Proposed rules for name resolution

tugwilson
Sorry, I should have added the palaver we go through to change a.b =  
1 into a.setB(1) and c = a.b into c = a.getB(), etc.

John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

RE: [groovy-jsr] Proposed rules for name resolution

Dierk König
In reply to this post by tugwilson
I'm not sure about the term 'point of use' for closures.
Does that mean 'point of declaration/instantiation'
or 'point of call' ?
(I guess the first, though...)

cheers
Mittie

> -----Original Message-----
> From: John Wilson [mailto:[hidden email]]
> Sent: Donnerstag, 17. November 2005 20:23
> To: [hidden email]
> Subject: [groovy-jsr] Proposed rules for name resolution
>
>
> All names are resolved in exactly the same way as in Java with the  
> following additions and exceptions:
>
> Additions
>
> 1/ Closures have names resolved first against any local variables in  
> scope at the point of use, second against any visible methods or  
> fields on the Closure object (these may be artificially limited so  
> that the closure doesn't see irrelevant methods and fields on the  
> Closure) third against any enclosing closure's local variables in  
> scope at the point of use (and so on out if there are multiple  
> enclosing closures), finally against the methods and fields of the  
> enclosing class (or against the local variables and the Binding if in  
> a script)
>
> 2/ Code in a Script resolves the name against local variables at the  
> point of use and then against the Binding.
>
> 3/ Names which cannot be resolved at compile time will cause an  
> exception to be thrown if an attempt is made to access it at run time.
>
> Exceptions:
>
> 1/ There are certain extremely obscure situations in which a private  
> item cannot be accessed on an object from within an object of the  
> same type.
>
>
> That's it!
>
> Any of this behaviour can, of course, be modified with a custom  
> metaclass and some of the behaviour can be modified using the methods  
> on Groovy Object
>
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Proposed rules for name resolution

Jochen Theodorou
In reply to this post by tugwilson
John Wilson schrieb:

> All names are resolved in exactly the same way as in Java with the  
> following additions and exceptions:
>
> Additions
>
> 1/ Closures have names resolved first against any local variables in  
> scope at the point of use, second against any visible methods or  fields
> on the Closure object (these may be artificially limited so  that the
> closure doesn't see irrelevant methods and fields on the  Closure) third
> against any enclosing closure's local variables in  scope at the point
> of use (and so on out if there are multiple  enclosing closures),
> finally against the methods and fields of the  enclosing class (or
> against the local variables and the Binding if in  a script)

when is a name a class?

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Proposed rules for name resolution

tugwilson
In reply to this post by Dierk König

On 17 Nov 2005, at 19:35, Dierk Koenig wrote:

> I'm not sure about the term 'point of use' for closures.
> Does that mean 'point of declaration/instantiation'
> or 'point of call' ?
> (I guess the first, though...)


yes your guess is right - thanks for the clarification.

{
     def a = 1

     { println a // prints 1}
}

{
     {println a // exception }
     def a = 1
}


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Proposed rules for name resolution

tugwilson
In reply to this post by Jochen Theodorou

On 17 Nov 2005, at 19:37, Jochen Theodorou wrote:

> John Wilson schrieb:
>
>> All names are resolved in exactly the same way as in Java with  
>> the  following additions and exceptions:
>> Additions
>> 1/ Closures have names resolved first against any local variables  
>> in  scope at the point of use, second against any visible methods  
>> or  fields on the Closure object (these may be artificially  
>> limited so  that the closure doesn't see irrelevant methods and  
>> fields on the  Closure) third against any enclosing closure's  
>> local variables in  scope at the point of use (and so on out if  
>> there are multiple  enclosing closures), finally against the  
>> methods and fields of the  enclosing class (or against the local  
>> variables and the Binding if in  a script)
>
> when is a name a class?

A name is a class if it is imported (explicitly or implicitly) or  
imported and aliased to the name and the name is not shadowed by  
another declaration of the same name.

This is the same rule as in Java isn't it?

John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Proposed rules for name resolution

Jochen Theodorou
John Wilson schrieb:

>
> On 17 Nov 2005, at 19:37, Jochen Theodorou wrote:
>
>> John Wilson schrieb:
>>
>>> All names are resolved in exactly the same way as in Java with  the  
>>> following additions and exceptions:
>>> Additions
>>> 1/ Closures have names resolved first against any local variables  
>>> in  scope at the point of use, second against any visible methods  
>>> or  fields on the Closure object (these may be artificially  limited
>>> so  that the closure doesn't see irrelevant methods and  fields on
>>> the  Closure) third against any enclosing closure's  local variables
>>> in  scope at the point of use (and so on out if  there are multiple  
>>> enclosing closures), finally against the  methods and fields of the  
>>> enclosing class (or against the local  variables and the Binding if
>>> in  a script)
>>
>>
>> when is a name a class?
>
> A name is a class if it is imported (explicitly or implicitly) or  
> imported and aliased to the name and the name is not shadowed by  
> another declaration of the same name.

And who tells me a name is a class? the compiler? MetaClass? and how is
shadowing done? I mean:

println x

x could be a class or a variable name that has to be resolved through
MetaClass.

> This is the same rule as in Java isn't it?

yes and no... In Java a variable can't be a class. It's seperate.

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Proposed rules for name resolution

tugwilson

On 17 Nov 2005, at 20:56, Jochen Theodorou wrote:

> John Wilson schrieb:
>> On 17 Nov 2005, at 19:37, Jochen Theodorou wrote:
>>> John Wilson schrieb:
>>>
>>>> All names are resolved in exactly the same way as in Java with  
>>>> the  following additions and exceptions:
>>>> Additions
>>>> 1/ Closures have names resolved first against any local  
>>>> variables  in  scope at the point of use, second against any  
>>>> visible methods  or  fields on the Closure object (these may be  
>>>> artificially  limited so  that the closure doesn't see  
>>>> irrelevant methods and  fields on the  Closure) third against  
>>>> any enclosing closure's  local variables in  scope at the point  
>>>> of use (and so on out if  there are multiple  enclosing  
>>>> closures), finally against the  methods and fields of the  
>>>> enclosing class (or against the local  variables and the Binding  
>>>> if in  a script)
>>>
>>>
>>> when is a name a class?
>> A name is a class if it is imported (explicitly or implicitly) or  
>> imported and aliased to the name and the name is not shadowed by  
>> another declaration of the same name.
>
> And who tells me a name is a class? the compiler? MetaClass? and  
> how is shadowing done? I mean:
>
> println x
>
> x could be a class or a variable name that has to be resolved  
> through MetaClass.

  No just like local on stack variables the compiler resolves the name.

>
>> This is the same rule as in Java isn't it?
>
> yes and no... In Java a variable can't be a class. It's seperate.

In Groovy (according to these rules) a variable can't be a class  
(unless a declaration shadows the name - just like Java)

John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Proposed rules for name resolution

Jochen Theodorou
John Wilson schrieb:

>
> On 17 Nov 2005, at 20:56, Jochen Theodorou wrote:
>
>> John Wilson schrieb:
>>
>>> On 17 Nov 2005, at 19:37, Jochen Theodorou wrote:
>>>
>>>> John Wilson schrieb:
>>>>
>>>>> All names are resolved in exactly the same way as in Java with  
>>>>> the  following additions and exceptions:
>>>>> Additions
>>>>> 1/ Closures have names resolved first against any local  variables  
>>>>> in  scope at the point of use, second against any  visible methods  
>>>>> or  fields on the Closure object (these may be  artificially  
>>>>> limited so  that the closure doesn't see  irrelevant methods and  
>>>>> fields on the  Closure) third against  any enclosing closure's  
>>>>> local variables in  scope at the point  of use (and so on out if  
>>>>> there are multiple  enclosing  closures), finally against the  
>>>>> methods and fields of the   enclosing class (or against the local  
>>>>> variables and the Binding  if in  a script)
>>>>
>>>>
>>>>
>>>> when is a name a class?
>>>
>>> A name is a class if it is imported (explicitly or implicitly) or  
>>> imported and aliased to the name and the name is not shadowed by  
>>> another declaration of the same name.
>>
>>
>> And who tells me a name is a class? the compiler? MetaClass? and  how
>> is shadowing done? I mean:
>>
>> println x
>>
>> x could be a class or a variable name that has to be resolved  through
>> MetaClass.
>
>  No just like local on stack variables the compiler resolves the name.

ok, this leads to the quiz on the dev list then ;)

>>> This is the same rule as in Java isn't it?
>>
>> yes and no... In Java a variable can't be a class. It's seperate.
>
> In Groovy (according to these rules) a variable can't be a class  
> (unless a declaration shadows the name - just like Java)

In java I can do:

Object String = Integer.class
System.out.println(String)

if I do that in groovy, then the compiler fails telling I tried to
assign a value to a class.. before my commit groovy accepted that but
simply printed String.class instead of Integer.class

so there is a difference.

And even if you say String should be a variable then, I still have the
problem that unbound variables in closures may be a class one time and a
dynamic variable another time.

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-jsr] Proposed rules for name resolution

tugwilson

On 17 Nov 2005, at 21:22, Jochen Theodorou wrote:

> In java I can do:
>
> Object String = Integer.class
> System.out.println(String)
>
> if I do that in groovy, then the compiler fails telling I tried to  
> assign a value to a class.. before my commit groovy accepted that  
> but simply printed String.class instead of Integer.class
>
> so there is a difference.
>
> And even if you say String should be a variable then, I still have  
> the problem that unbound variables in closures may be a class one  
> time and a dynamic variable another time.

Yes, but I'm proposing a change to the current behaviour. The  
compiler should do what the java compiler does and resolve String to  
the local variable called String.

Unbound variables in closures or in classes are handled by the  
MetaClass the default MetaClass will throw an exception.


John Wilson
The Wilson Partnership
http://www.wilson.co.uk