[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-user
Subject:    Re: [groovy-user] Assigment statement in closure
From:       "Nebojsa Vasiljevic" <nebojsa () sw4i ! com>
Date:       2005-04-20 21:14:21
Message-ID: 003501c545ee$0fec3b00$9c8666d4 () mediacenter ! org ! yu
[Download RAW message or body]

----- Original Message ----- 
From: "Jochen Theodorou" <blackdrag@uni.de>

> We will support dynamic scopes, but not in general. All Groovy classes 
> which are implementing GroovyObject are currently able to intercept 
> property assignment or read of properies. This will change in the 
> feature because this way a variable name does not require to really 
> exist. This means there is no check possible, neither for the type nor 
> for the name.

When I say "dynamic scopes" I mean dynamic nesting: outer scope is defined by
caller.

Groovy uses static (early) bindings for local variables, dynamic (late) bindings for
method calls and properties, more or less static (lexical) scopes, and there is a
dirty trick with setDelegate(). 

Scope/binding semantic of groovy is not very clear.

In my most "Outher scope overrides inner scope", setDelegate() is one half of issue, \
other half of issue is:  "foo()" is sometimes  "this.invokeMethod('foo')", but \
sometimes "foo.doCall()". In first case, "foo" just string literal, but in second \
case "foo" is banded to a  variable definition.

As we can see even method binding is not clear: we don't know that  \
"this.invokeMethod('foo')" will invoke method defined as "foo". BTW, "invokeMethod()" \
is another dirty trick.

In most programming languages, dynamic binding is a map (hast table or something like \
that): you dynamically define by putting in map and dynamically resolve by getting \
from map. Real binding is hidden in  "retrieveMethod()" method of "MetaClass". \
GroovyObject interface should expose binding itself.

Nebojsa

> 
> About your line:
> c = { foo1; foo2(); foo3 = "bar" };
> 
> in a script the part "foo3="bar"" does not access a property, instead a 
> it is like "def foo3="bar"", which means a local variable is created. 
> This means we have a completely new varibale here and the setter methods 
> are only called if the variable is a property. Maybe you see now why we 
> want to remove the delegate. Please note also, there is currently no 
> check for requiered defs or things like that.
> 
> bye blackdrag
> 


[prev in list] [next in list] [prev in thread] [next in thread]