Hi

Perhaps I misunderstand, but it seems you have an ordered collection
whose order you are unhappy with.

Surely the solution is either to make the collection unordered, or to
fix-up your assignment algorithm so that it is sensibly ordered?

EMF unordered collections are realised by ELists so that they do
actually have an order that can be inconvenient if you use something
like org.eclipse.xtext.util.EmfFormatter as the basis for a
JUnit-friendly model comparison. For that purpose, I use a hierarchy of
Normalizer classes, so that a first traversal pass over the model
gathers all the normalizations that are necessary, then the
normalizations can be performed in a second 'pass' without corrupting an
iterator domain. Once normalized, 'equivalent' models can be compared
for exact equality. But as EdM observed, modifying models is dubious. It
is often tolerable at the end of JUnit tests., however where
intolerable, the Normalizers support an inverse denormalization
operation so that the normalization can be reverted.

Your Comparator assumes that getEKeys() is the basis for an ordering.
There are many different comparisons, so hardwiring one doesn't seem
helpful.

An idea! Rather than a disruptive normalizer, why not provide an Guava
Iterable that presents a normalized view of your collection? An
EStructuralFeature to NormalizedIteratableFactory registry could provide
something extensible and neutral.

Regards

Ed Willink


On 03/03/2015 08:46, Mark Hoffmann wrote:
> Hello together,
>
> I noticed that the 'ordered' feature in the ecore has no influence on
> the code generation process. It is no bigger problem until now.
> Currently I have a use case where I want to compare to model instance
> for equality. But there are many-references with content that has not
> the same order in the list. The order is not important for the
> equality in this case, but only the content of the objects.
>
> For that I created my own EqualityHelper extending the
> EcoreUtil.EqualityHelper to support sorting like this:
>
> protected boolean haveEqualReference(EObject eObject1, EObject
> eObject2, EReference reference) {
> Object value1 = eObject1.eGet(reference);
> Object value2 = eObject2.eGet(reference);
> if (reference.isMany()) {
> List<EObject> list1 = (List<EObject>) value1;
> List<EObject> list2 = (List<EObject>) value2;
> if (reference.isOrdered()) {
> Comparator<EObject> comparator = new
> EObjectComparator(reference.getEKeys());
> Collections.sort(list1, comparator);
> Collections.sort(list2, comparator);
> }
> return equals(list1, list2);
> } else {
> return equals((EObject)value1, (EObject)value2);
> }
> }
>
>
> The comparator sorts depending on the keys, if any are given,
> otherwise it uses toString comparison. The values in the key
> attributes are checked, if they implement java.lang.Comparable, which
> works for Numbers, String, Date and Enums
>
> What do you think of this pattern? Is it something to contribute to
> enhance the EcoreUtil.EqualityHelper? Because this use-case is
> probalby not the most common one, maybe it should be parameterized.
> EcoreUtil.equals(EObject eObject1, EObject eObject2, boolean sort)
>
> By the way my implementation supports ignore-features too, that are
> ignored during comparison when they are not important for the equality.
>
> Regards,
> Mark