[prev in list] [next in list] [prev in thread] [next in thread]
List: groovy-scm
Subject: [jira] Commented: (GROOVY-1163) refactor void GroovyObject.setMetaClass() {} to something like Objec
From: "John Wilson (JIRA)" <jira () codehaus ! org>
Date: 2005-11-28 12:22:06
Message-ID: 94804515.1133180526215.JavaMail.haus-jira () codehaus01 ! managed ! contegix ! com
[Download RAW message or body]
[ http://jira.codehaus.org/browse/GROOVY-1163?page=comments#action_52183 ]
John Wilson commented on GROOVY-1163:
-------------------------------------
I think this is intrinsically a good idea. Changing the MetaClass of a live object in \
a muti threaded environment is not a healthy thing to do.
A consequence of this (I think) is that all Groovy Objects have to be Clonable so \
GroovyObject should extend Clonable.
If we are making breaking changes to GroovyObject then we should take the opportunity \
to align the method signatures of invokeMethod and get/setProperty with the new MOP.
Should we add get/setAttribute?
> refactor void GroovyObject.setMetaClass() {} to something like Object \
> GroovyObject.become(MetaClass) {}
> -------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-1163
> URL: http://jira.codehaus.org/browse/GROOVY-1163
> Project: groovy
> Type: New Feature
> Reporter: james strachan
> Assignee: Guillaume Laforge
>
>
> So that we can coerce one object into another, but returning a new object reference \
> in case we need to do some bytecode magic etc
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic