Re: Yikes! String is mutable! (was Re: [groovy-user] XMLParser: attribute gets truncated when updated)

Jim White schrieb:
[...]
> As I say there, it is time to close the gaping hole and should do it for
> 1.6.  If it is too big an incompatiblity, and some users can't deal with
> it right away (this being so close to time for 1.6RC1), then we can have
> a switch to enable the old behavior for them.

The problem is that the current MOP is not good enough to resolve this
kind of situation. Let me show you an example:


class X {
   private foo
   def bar() {
     return {this.@foo}
   }
   def setFoo(x){foo=x}
}

def x = new X()
x.setFoo(1)
assert x.bar().call() == 1

i this case it is quite clear, that this.@foo means the private field,
we can resolve it statically and last theoretically we could solve this
case... Now let us change the closure a little:

class X {
   private foo
   def bar() {
     return {foo}
   }
   def setFoo(x){foo=x}
}

def x = new X()
x.setFoo(1)
assert x.bar().call() == 1

it is more or less the same code, but now foo is a property in the first
place. Meaning that the lookup will be done using getProperty in
Closure. This method does not transport the caller class, so we can not
verify that the closure has access to foo.

The whole thing is totally blowing up when you do:

class X {
   private foo
   def bar() {
     return {foo}
   }
   def setFoo(x){foo=x}
}
class Y extends X{}

def x = new Y()
x.setFoo(1)
assert x.bar().call() == 1

even with the current information stored in the MOP and not going
through getPropterty, we still have the problem that the caller class is
actually the Closure and not X. But since the private field foo is now
only available in X and not in Y this example will fail even in current
Groovy. And what counts for getProperty partially counts for
invokeMethod too, but the problem is not as big there, as invokeMethod
is usually only called if the normal method call fails. Of course that
also means that Interceptable successfully deletes any access
information during the method call.

Not to mention that transporting the type information and checking
access rights is bad for the runtime performance

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/

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

    http://xircles.codehaus.org/manage_email