Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [EMF] Choose internally used EList (sets which use '==' or 'equals')
[EMF] Choose internally used EList (sets which use '==' or 'equals') [message #1057149] Wed, 08 May 2013 07:27 Go to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
Registered: July 2010
Senior Member
Could someone give me a short hint, where I can find code snippets or documentation how the internally used EList can be chosen. I have an EMF model, and I want to specify that some sets (EList) work with 'equals' and some with '=='. 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.

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?

Thanks in advance!
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26127
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!
Re: [EMF] Choose internally used EList (sets which use '==' or 'equals') [message #1057155 is a reply to message #1057152] Wed, 08 May 2013 09:43 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4086
Registered: July 2009
Senior Member
Hi

On 08/05/2013 08:40, Ed Merks wrote:
>> I have an EMF model, and I want to specify that some sets (EList)
>> work with 'equals' and some with '=='.
....
> Probably you're going down a dangerous path...
Indeed. Object.equals() is absolutely to the smooth working of Java
Collection classes, particularly Set.

EMF has a pragmatic optimization that works so long as you don't
invalidate the assumptions.

If your semantics of equality differ from Java's then expect trouble
downstream if you ever try to make them the same.

For OCL, the seemingly trivial requirement that 1.0 is consistently
equal to 1 causes an amazing amount of difficulty. The 'clean' solution
of an alternative class hierarchy in which Object::equals is overloaded
with OCL semantics works nicely but incurs unacceptable overheads since
every EObject, String, ... has to have a wrapping object ... so a less
clean solution ...

Regards

Ed Willink
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 Go to previous messageGo to next message
Kirsten M. Z. is currently offline Kirsten M. Z.
Messages: 131
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 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26127
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.
Previous Topic:[Teneo] session refresh throws UnresolvableObjectException: No row with the given identifier exists
Next Topic:[CDO] Does actually work with PostgreSQL or Oracle?
Goto Forum:
  


Current Time: Tue Oct 21 07:26:34 GMT 2014

Powered by FUDForum. Page generated in 0.02878 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software