Eclipse Community Forums: EMF "Technology" (Ecore Tools, EMFatic, etc)

Help

Home

Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » Suggestions for EqualityHelper

Show: Today's Messages :: Show Polls :: Message Navigator

Suggestions for EqualityHelper [message #130778]

Thu, 06 November 2008 22:33

Jim Showalter

Messages: 6
Registered: July 2009

Junior Member

Currently EqualityHelper fails on the first mismatch, returns no
information about what didn't match to the caller, and does not provide a
way to change behavior or filter out mismatches that aren't important to
the caller.

For example, if a caller doesn't care about changes only to order, they
have to do this: http://jorgemanrubia.net/2008/07/06/comparing-emf-models.

And if a caller doesn't want to compare IDs (for example, because they
want to test the output of a modeling tool by comparing .model files,
where the IDs in the .model files are randomly seeded and therefore not
reproducible on subsequent runs), they have to copy the big equals method
and add if (feature.getName().compareToIgnoreCase("id") != 0) to the for
loop that compares values.

And so forth.

EqualityHelper could be revamped to post diff events. The events would
contain information about the mismatch that caused the event. A caller
could filter out events they don't care about (for example, order changes,
mismatched IDs, etc.).

More challenging but also useful would be continuing after finding a
mismatch, similar to how a compiler tries to recover instead of stopping
on the first error.

Does anyone else thing this would be worth doing? If so, would they be
interested in collaborating on it?

Report message to a moderator

Re: Suggestions for EqualityHelper [message #130792 is a reply to message #130778]

Thu, 06 November 2008 23:03

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------010103000001090302050507
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Jim,

Comments below.

Jim Showalter wrote:
> Currently EqualityHelper fails on the first mismatch,
You mean EcoreUtil.EqualityHelper? Not equal is not equal...
> returns no information about what didn't match to the caller,
It computes a map of things that are assumed to be equal and have not
proven to be non-equal...
> and does not provide a way to change behavior or filter out mismatches
> that aren't important to the caller.
It's a class that's been factored such that you can override the
behavior. It's not all that big and the factored methods are small...
>
> For example, if a caller doesn't care about changes only to order,
> they have to do this:
> http://jorgemanrubia.net/2008/07/06/comparing-emf-models.
The compare framework is intended to deal with the generally very hard
problem of comparing to instances. EcoreUtil.EqualityHelper is intended
primarily to be a simple way to support testing for structural equality.
>
> And if a caller doesn't want to compare IDs (for example, because they
> want to test the output of a modeling tool by comparing .model files,
> where the IDs in the .model files are randomly seeded and therefore
> not reproducible on subsequent runs), they have to copy the big equals
> method and add if (feature.getName().compareToIgnoreCase("id") != 0)
> to the for loop that compares values.
Can you imagine all the variations on this theme?

Are you suggesting something that would meaningfully refactor this
method? I would imagine that haveEqualFeature could be used to deal
with case insensitive testing of equality of a particular feature's
value. No?
>
> And so forth.
>
> EqualityHelper could be revamped to post diff events.
It's primary purpose is to return true or false. The compare framework
is designed for detailed comparison including computation of deltas...
> The events would contain information about the mismatch that caused
> the event. A caller could filter out events they don't care about (for
> example, order changes, mismatched IDs, etc.).
Yes, that's what the compare framework is for...

http://live.eclipse.org/node/616

>
> More challenging but also useful would be continuing after finding a
> mismatch, similar to how a compiler tries to recover instead of
> stopping on the first error.
>
> Does anyone else thing this would be worth doing? If so, would they be
> interested in collaborating on it?
Comparison, delta computation, and merging of changes are shockingly
difficult problems given how simply they seem on the surface. The
EqualityHelper is a trivial implementation (a few hundred lines of code)
and is not intended to do the kinds of things you outline. The compare
component is focused on that, so it would be best to focus on what it
provides and work with folks like Cedric on making it even more
powerful. Establishing a correspondence between two instances is in and
of itself a hard problem. Assuming that ID's don't change or that you
have UUIDs helps a lot, but failing that, it gets more difficult. The
compare framework has various ways to specialize the way correspondence
is established...

--------------010103000001090302050507
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jim, 
 
Comments below. 
 
Jim Showalter wrote:
<blockquote
cite="mid:9f061adb7f994dd201da09cb9df6adc9$1@www.eclipse.org"
type="cite">Currently EqualityHelper fails on the first mismatch,</blockquote>
You mean EcoreUtil.EqualityHelper?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: Suggestions for EqualityHelper [message #130874 is a reply to message #130792]

Tue, 11 November 2008 17:34

Jim Showalter

Messages: 6
Registered: July 2009

Junior Member

The code at http://jorgemanrubia.net/2008/07/06/comparing-emf-models
doesn't actually work (he's substituting the hashcode of the String
returned by toString() instead of the hashcode of the EObject, and there
are other problems I reported), and he's aware of that and will fix it.
But it was that post that got me thinking about doing a full diff instead
of just failing on the first error. And it turns out it's trivial to do
that--that's what EMF Compare already does. I just needed to use the
compare routines instead of equals, as described here:
http://wiki.eclipse.org/EMF_Compare_FAQ#How_can_I_use_EMF_Co mpare_programmatically.3F.

Report message to a moderator

Re: Suggestions for EqualityHelper [message #620395 is a reply to message #130778]

Thu, 06 November 2008 23:03

Ed Merks

Messages: 33142
Registered: July 2009

Senior Member

This is a multi-part message in MIME format.
--------------010103000001090302050507
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Jim,

Comments below.

Jim Showalter wrote:
> Currently EqualityHelper fails on the first mismatch,
You mean EcoreUtil.EqualityHelper? Not equal is not equal...
> returns no information about what didn't match to the caller,
It computes a map of things that are assumed to be equal and have not
proven to be non-equal...
> and does not provide a way to change behavior or filter out mismatches
> that aren't important to the caller.
It's a class that's been factored such that you can override the
behavior. It's not all that big and the factored methods are small...
>
> For example, if a caller doesn't care about changes only to order,
> they have to do this:
> http://jorgemanrubia.net/2008/07/06/comparing-emf-models
The compare framework is intended to deal with the generally very hard
problem of comparing to instances. EcoreUtil.EqualityHelper is intended
primarily to be a simple way to support testing for structural equality.
>
> And if a caller doesn't want to compare IDs (for example, because they
> want to test the output of a modeling tool by comparing .model files,
> where the IDs in the .model files are randomly seeded and therefore
> not reproducible on subsequent runs), they have to copy the big equals
> method and add if (feature.getName().compareToIgnoreCase("id") != 0)
> to the for loop that compares values.
Can you imagine all the variations on this theme?

Are you suggesting something that would meaningfully refactor this
method? I would imagine that haveEqualFeature could be used to deal
with case insensitive testing of equality of a particular feature's
value. No?
>
> And so forth.
>
> EqualityHelper could be revamped to post diff events.
It's primary purpose is to return true or false. The compare framework
is designed for detailed comparison including computation of deltas...
> The events would contain information about the mismatch that caused
> the event. A caller could filter out events they don't care about (for
> example, order changes, mismatched IDs, etc.).
Yes, that's what the compare framework is for...

http://live.eclipse.org/node/616

>
> More challenging but also useful would be continuing after finding a
> mismatch, similar to how a compiler tries to recover instead of
> stopping on the first error.
>
> Does anyone else thing this would be worth doing? If so, would they be
> interested in collaborating on it?
Comparison, delta computation, and merging of changes are shockingly
difficult problems given how simply they seem on the surface. The
EqualityHelper is a trivial implementation (a few hundred lines of code)
and is not intended to do the kinds of things you outline. The compare
component is focused on that, so it would be best to focus on what it
provides and work with folks like Cedric on making it even more
powerful. Establishing a correspondence between two instances is in and
of itself a hard problem. Assuming that ID's don't change or that you
have UUIDs helps a lot, but failing that, it gets more difficult. The
compare framework has various ways to specialize the way correspondence
is established...

--------------010103000001090302050507
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Jim, 
 
Comments below. 
 
Jim Showalter wrote:
<blockquote
cite="mid:9f061adb7f994dd201da09cb9df6adc9$1@www.eclipse.org"
type="cite">Currently EqualityHelper fails on the first mismatch,</blockquote>
You mean EcoreUtil.EqualityHelper?

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator