Home » Modeling » EMF » [EMF] Choose internally used EList (sets which use '==' or 'equals')
|
Re: [EMF] Choose internally used EList (sets which use '==' or 'equals') [message #1057152 is a reply to message #1057149] |
Wed, 08 May 2013 07:40 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Kirsten,
Comments below.
On 08/05/2013 9:27 AM, Kirsten M. Z. wrote:
> Could someone give me a short hint, where I can find code snippets or
> documentation how the internally used EList can be chosen.
You don't choose it. The generate chooses the correct one based on the
details of the structural feature.
> I have an EMF model, and I want to specify that some sets (EList) work
> with 'equals' and some with '=='.
Why? It sounds like you'd be doing that in conjunction with
specializing the equals/hashCode of some EObject implementation class
but if you read the Javadoc for EObject, you'll see that's now
permitted/supported:
The framework also assumes that implementations will not specialize
equals(Object) (nor hashCode()) so that "==" can be always used for
equality testing; EcoreUtil.equals should be used for doing structural
equality testing.
> I found many statements that there are different implementations of
> EList which allow many kinds of behavior (BasicEList.FastCompare<E>
> etc), but I could not find further documentation how it should be used
> exactly.
Probably you're going down a dangerous path...
>
> Is there a way to specify such things, or do I have to adjust the
> generated code?
> And what about the reflective EMF, so without code generation? Delegates?
They all behave correctly without you needing to take action. E.g., for
EObject containing lists (i.e., for multi-valued references), == is
used, and for multi-valued attributes, .equals is used. Both will
produce the correct behavior, with the assumption that you don't
specialize equals and hashCode for your EObjects. If you feel a need to
specialize those methods, what your implementing shouldn't be EObject
but data values.
>
> Thanks in advance!
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: [EMF] Choose internally used EList (sets which use '==' or 'equals') [message #1057773 is a reply to message #1057152] |
Wed, 08 May 2013 16:26 |
Kirsten M. Z. Messages: 132 Registered: July 2010 |
Senior Member |
|
|
Quote:for EObject containing lists (i.e., for multi-valued references), == is used, and for multi-valued attributes, .equals is used
Ahhh, this was the fact I really missed. I expected, that I have to specify that .equals is used for attribute (E)lists. Implementing .equals for my EObjects was not my (first) intention. However, I know that this is not allowed now.
Just for curiosity: if I understood you correctly, it is not meaningful to implement an EClass with string semantics then? Typically, this would require, that lists containing such string objects and 'unique=true' would use equals (or EcoreUtil.equals) instead of the 'real' object's identity (==)
|
|
|
Re: [EMF] Choose internally used EList (sets which use '==' or 'equals') [message #1057962 is a reply to message #1057773] |
Fri, 10 May 2013 07:34 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Kirsten,
Comments below.
On 08/05/2013 6:26 PM, Kirsten M. Z. wrote:
> Quote:
>> for EObject containing lists (i.e., for multi-valued references), ==
>> is used, and for multi-valued attributes, .equals is used
>
>
> Ahhh, this was the fact I really missed. I expected, that I have to
> specify that .equals is used for attribute (E)lists. Implementing
> .equals for my EObjects was not my (first) intention. However, I know
> that this is not allowed now.
>
> Just for curiosity: if I understood you correctly, it is not
> meaningful to implement an EClass with string semantics then?
EObjects are not "value" objects. I.e., they generally can and do
change state, so if the hash code depends on the state, any structure
relying on a fixed hash code (e.g., any hash-based collection) will
become corrupt when the state of the objects uses as keys changes.
> Typically, this would require, that lists containing such string
> objects and 'unique=true' would use equals (or EcoreUtil.equals)
> instead of the 'real' object's identity (==)
Yes, that's true. Proper collection semantics requires the use of
..equals in general, so any EMF lists that use == violate the collection
library contracts, except when it's the case that .equals and == have
the same semantics. Note that this is a stronger statement than you
just made. I.e., even proper semantics for contains testing whether the
collection is unique or not, always requires the use of equals.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Mar 29 01:31:27 GMT 2024
Powered by FUDForum. Page generated in 0.03651 seconds
|