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 12:03  |
Eclipse User |
|
|
|
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] |
Wed, 09 February 2011 22:58  |
| Eclipse User |
|
|
|
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
|
|
|
| Re: Overriding EcoreUtil.copy behaviour to make a truly 'self-contained' copy [message #653557 is a reply to message #653417] |
Thu, 10 February 2011 04:03 |
| Eclipse User |
|
|
|
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.
|
|
|
Goto Forum:
Current Time: Wed Jul 23 06:24:14 EDT 2025
Powered by FUDForum. Page generated in 0.05300 seconds |
Home