Jochen Theodorou | 1 Aug 00:13
Gravatar

[groovy-dev] HandleMetaClass

Hi all,

looks like the class HandleMetaclasswas added. It seems to be a proxy to 
the real meta class. I might have missed something, but when did we 
discuss this change?

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

Jochen Theodorou | 1 Aug 00:58
Gravatar

Re: [groovy-dev] HandleMetaClass

Jochen Theodorou schrieb:
> Hi all,
> 
> looks like the class HandleMetaclasswas added. It seems to be a proxy to 
> the real meta class. I might have missed something, but when did we 
> discuss this change?

as a result of that change this script is now true:

>         def cl = {}
>         def orig = cl.getMetaClass()
>         cl.setMetaClass(null)
>         def meta = cl.getClass().metaClass
>         assert meta != ExpandoMetaClass.class
>         assert orig == meta
>         assert orig.delegate == meta.delegate

where in Groovy before this change the script would have been:

>         def cl = {}
>         def orig = cl.getMetaClass()
>         cl.setMetaClass(null)
>         def meta = cl.getClass().metaClass
>         assert meta == ExpandoMetaClass.class
>         assert orig != meta

this is a breaking change, because it is now no longer possible to 
delete a per instance meta class by using foo.metaClass=null.

Looks like changeset 12708 introduced the class a while ago. In
(Continue reading)

Alex Tkachman | 1 Aug 14:17

Re: [groovy-dev] HandleMetaClass

>
>>        def foo(x) { x._100 }
>>        def x = Integer.valueOf(22)
>>        ExpandoMetaClass emc = new ExpandoMetaClass(Integer, false,
>> true).define {
>>            _100 = 100
>>        }
>>        emc.initialize ()
>>        x.metaClass = emc
>>
>> assert foo(x) == 100
>> assert foo(1) == 100
>> assert 1._100 == 100
>
> if it is per instance, then only x should have been changed. If I run the
> program, than I see that foo(1) works just as well as foo(x), which means it
> is not per instance. On the other hand 1._100 fails with a
> MissingPropertyException as it should. My only guess is that the per
> instance meta class is just a compiler trick here and not real.
>

it is bug in call site caching. good catch!

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

    http://xircles.codehaus.org/manage_email

Jochen Theodorou | 1 Aug 15:50
Gravatar

Re: [groovy-dev] HandleMetaClass

Alex Tkachman schrieb:
>>>        def foo(x) { x._100 }
>>>        def x = Integer.valueOf(22)
>>>        ExpandoMetaClass emc = new ExpandoMetaClass(Integer, false,
>>> true).define {
>>>            _100 = 100
>>>        }
>>>        emc.initialize ()
>>>        x.metaClass = emc
>>>
>>> assert foo(x) == 100
>>> assert foo(1) == 100
>>> assert 1._100 == 100
>> if it is per instance, then only x should have been changed. If I run the
>> program, than I see that foo(1) works just as well as foo(x), which means it
>> is not per instance. On the other hand 1._100 fails with a
>> MissingPropertyException as it should. My only guess is that the per
>> instance meta class is just a compiler trick here and not real.
> 
> it is bug in call site caching. good catch!

say, was there any discussion of if we are going to allow per instance 
meta classes for java objects, or not? I don't remember anything like that.

bye blackdrag

--

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

Alex Tkachman | 1 Aug 07:22

Re: [groovy-dev] HandleMetaClass

It is just implementation detail for per instance meta classes. The
idea is to keep reference for source class or object, when we take it
from somewhere and to be able to mutate it later.

On Fri, Aug 1, 2008 at 2:14 AM, Jochen Theodorou <blackdrag@...> wrote:
> Hi all,
>
> looks like the class HandleMetaclasswas added. It seems to be a proxy to the
> real meta class. I might have missed something, but when did we discuss this
> change?
>
> 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
>
>
>

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

(Continue reading)

Jochen Theodorou | 1 Aug 10:54
Gravatar

Re: [groovy-dev] HandleMetaClass

Alex Tkachman schrieb:
> It is just implementation detail for per instance meta classes. The
> idea is to keep reference for source class or object, when we take it
> from somewhere and to be able to mutate it later.

Alex, it is an implementation detail if the user will not see any 
changes in his code. This is not the case. It broke much of my code for 
example. And worse, we had the idiom that foo.metaClass=null will remove 
the per instance MetaClass on foo is foo is an instance of GroovyObject. 
This is no longer the case. As of this, it is not an implementation 
detail, but a breaking change. How am I supposed to do that now?

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

Alex Tkachman | 1 Aug 10:56

Re: [groovy-dev] HandleMetaClass

Of course, foo.metaClass = null MUST remove per instance meta class.
if it doesn't it is a bug to be fixed and I will have a look later
today. I guess the problem is somewhere in call site caching

On Fri, Aug 1, 2008 at 12:54 PM, Jochen Theodorou <blackdrag@...> wrote:
> Alex Tkachman schrieb:
>>
>> It is just implementation detail for per instance meta classes. The
>> idea is to keep reference for source class or object, when we take it
>> from somewhere and to be able to mutate it later.
>
> Alex, it is an implementation detail if the user will not see any changes in
> his code. This is not the case. It broke much of my code for example. And
> worse, we had the idiom that foo.metaClass=null will remove the per instance
> MetaClass on foo is foo is an instance of GroovyObject. This is no longer
> the case. As of this, it is not an implementation detail, but a breaking
> change. How am I supposed to do that now?
>
> 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
(Continue reading)

Jochen Theodorou | 1 Aug 11:00
Gravatar

Re: [groovy-dev] HandleMetaClass

Alex Tkachman schrieb:
> Of course, foo.metaClass = null MUST remove per instance meta class.
> if it doesn't it is a bug to be fixed and I will have a look later
> today. I guess the problem is somewhere in call site caching

well, see my other mail from this night. I included two example scripts 
showing the old and new behaviour.. the script for the new behaviour is 
showing that the Metaclass is not exchanged.. or it was late... 
Nevertheless... is there a specific reasons as of why foo.metaClass must 
return the handle?

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

Alex Tkachman | 1 Aug 11:06

Re: [groovy-dev] HandleMetaClass

Because otherwise foo.metaClass.bar = {...} will modify meta class in
registry in case of GroovyObject and per instance meta class in case
of POJO

On Fri, Aug 1, 2008 at 1:00 PM, Jochen Theodorou <blackdrag@...> wrote:
> Alex Tkachman schrieb:
>>
>> Of course, foo.metaClass = null MUST remove per instance meta class.
>> if it doesn't it is a bug to be fixed and I will have a look later
>> today. I guess the problem is somewhere in call site caching
>
> well, see my other mail from this night. I included two example scripts
> showing the old and new behaviour.. the script for the new behaviour is
> showing that the Metaclass is not exchanged.. or it was late...
> Nevertheless... is there a specific reasons as of why foo.metaClass must
> return the handle?
>
> 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
>
(Continue reading)


Gmane