Home » Modeling » EMF » Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy((for my specific use-case, not suggesting a change to EMF))
| Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy [message #653417] |
Wed, 09 February 2011 17:03  |
 Ben Tenne
Messages: 50
Registered: October 2009 |
Member |
|
|
I noticed that the Javadoc comment for EcoreUtil.copy(EObject) states that it "Returns a self-contained copy of the eObject". I then observed that EAttributes (non-primitive) are not duplicated in the copy, but the existing instances in the source object hierarchy are referenced.
This is consistent with a passage in The Book: "...the values themselves are not copied. So if an EObject has a mutable object as the value of a non-primitive attribute, that mutable object can be changed by code that is interacting with either the original or the copied EObject."
In my case, I'm not using primitives or any special types to back attributes. Neither am I using non-containments. My attributes are always one of: String, Integer, Boolean Double, BigInteger, BigDecimal, XMLGregorianCalendar, Duration and FeatureMap. Given that FeatureMaps are dealt with as a special case during copying, the only one of these that is mutable is XMLGregorianCalendar. Therefore, if I can alter the copy behaviour to explicitly create copies of XMLGregorianCalendars, then I get a truly self-contained copy of my root EObject.
I was thinking of doing this by extending EcoreUtil and overriding copyAttribute(EAttribute eAttribute, EObject eObject, EObject copyEObject). The code change would simply check to see if the attribute is an XMLGregorianCalendar and clone it. Alternatively, I could see if the attribute object's class implements Cloneable and use that as an indication that it's probably mutable, and clone it (harmless, either way).
Does this sound reasonable?
Cheers,
Ben.
|
|
|
| Re: Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy [message #653513 is a reply to message #653417] |
Thu, 10 February 2011 03:58  |
|
Am 09.02.2011 18:03, schrieb Ben Tenne:
> I noticed that the Javadoc comment for EcoreUtil.copy(EObject) states that it "Returns a self-contained copy of the eObject". I then observed that EAttributes (non-primitive) are not duplicated in the copy, but the existing instances in the source object hierarchy are referenced.
>
> This is consistent with a passage in The Book: "...the values themselves are not copied. So if an EObject has a mutable object as the value of a non-primitive attribute, that mutable object can be changed by code that is interacting with either the original or the copied EObject."
>
> In my case, I'm not using primitives or any special types to back attributes. Neither am I using non-containments. My attributes are always one of: String, Integer, Boolean Double, BigInteger, BigDecimal, XMLGregorianCalendar, Duration and FeatureMap. Given that FeatureMaps are dealt with as a special case during copying, the only one of these that is mutable is XMLGregorianCalendar. Therefore, if I can alter the copy behaviour to explicitly create copies of XMLGregorianCalendars, then I get a truly self-contained copy of my root EObject.
>
> I was thinking of doing this by extending EcoreUtil and overriding copyAttribute(EAttribute eAttribute, EObject eObject, EObject copyEObject). The code change would simply check to see if the attribute is an XMLGregorianCalendar and clone it. Alternatively, I could see if the attribute object's class implements Cloneable and use that as an indication that it's probably mutable, and clone it (harmless, either way).
>
> Does this sound reasonable?
Yes ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy [message #653557 is a reply to message #653417] |
Thu, 10 February 2011 09:03 |
Ed Merks
Messages: 33141
Registered: July 2009 |
Senior Member |
|
|
Ben,
Comments below.
Ben Tenne wrote:
> I noticed that the Javadoc comment for EcoreUtil.copy(EObject) states
> that it "Returns a self-contained copy of the eObject". I then
> observed that EAttributes (non-primitive) are not duplicated in the
> copy, but the existing instances in the source object hierarchy are
> referenced.
Attribute values are effectively assumed to be things that generally
have no modifiable state and can be shared...
>
> This is consistent with a passage in The Book: "...the values
> themselves are not copied. So if an EObject has a mutable object as
> the value of a non-primitive attribute, that mutable object can be
> changed by code that is interacting with either the original or the
> copied EObject."
>
> In my case, I'm not using primitives or any special types to back
> attributes. Neither am I using non-containments. My attributes are
> always one of: String, Integer, Boolean Double, BigInteger,
> BigDecimal, XMLGregorianCalendar, Duration and FeatureMap. Given that
> FeatureMaps are dealt with as a special case during copying, the only
> one of these that is mutable is XMLGregorianCalendar. Therefore, if I
> can alter the copy behaviour to explicitly create copies of
> XMLGregorianCalendars, then I get a truly self-contained copy of my
> root EObject.
>
> I was thinking of doing this by extending EcoreUtil and overriding
> copyAttribute(EAttribute eAttribute, EObject eObject, EObject
> copyEObject). The code change would simply check to see if the
> attribute is an XMLGregorianCalendar and clone it. Alternatively, I
> could see if the attribute object's class implements Cloneable and use
> that as an indication that it's probably mutable, and clone it
> (harmless, either way).
>
> Does this sound reasonable?
Yes.
>
> Cheers,
> Ben.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 19:44:33 GMT 2024
Powered by FUDForum. Page generated in 0.02963 seconds |
] 
Search
Help
Register
Login
Home
