[EMF Compare] Usage of MatchOptions.OPTION_DISTINCT_METAMODELS [message #695863] |
Tue, 12 July 2011 16:32 |
Eclipse User |
|
|
|
Originally posted by:
Hi guys,
while debugging a bit, I realized GenericMatchEngine was using
DistinctEcoreSimilarityChecker when it wasn't my intention. Looking at
the code I found at GenericMatchEngine.prepareChecker():
if (!structuredOptions.shouldMatchDistinctMetamodels()) {
checker = new DistinctEcoreSimilarityChecker(filter, bridge);
} else {
checker = new StatisticBasedSimilarityChecker(filter, bridge);
}
so, if we set option MatchOptions.OPTION_DISTINCT_METAMODELS to false,
it will actually use it. Looking at the javadoc of this option, it
specifies the following:
> Key for the option specifying whether the compared models are of distinct meta-models.
So, If i say "no, my models do not conform to distinct metamodels", I'll
conclude I should put that option to false. But the logic at
GenericMatchEngine.prepareChecker() is negated, so it will actually use
DistinctEcoreSimilarityChecker.
Was this meant to be like that, or is it a bug? Maybe javadoc is not
clear enough?
Cheers,
Víctor.
|
|
|
|
Re: [EMF Compare] Usage of MatchOptions.OPTION_DISTINCT_METAMODELS [message #696322 is a reply to message #696213] |
Wed, 13 July 2011 17:14 |
Eclipse User |
|
|
|
Originally posted by:
Hi Cedric,
I'm sorry but I may be missing something. Still I can't see how any of
those javadocs should lead me to conclude that I must pass a TRUE value
instead of FALSE to use StatisticBasedSimilarityChecker. It's no big
deal, just wanted to clarify that and help improving javadoc, if there
is any room for that ;)
Cheers!
Víctor.
Cedric Brun escribió:
> Hi Victor,
>
> in fact the misnaming exists, but it's DistinctEcoreSimilarityChecker.
> Here is the javadoc :
>
> * Specialization of the heuristic based similarity checker making sure
> before computing complex metrics that both EClasses are the same.
>
>
|
|
|
Re: [EMF Compare] Usage of MatchOptions.OPTION_DISTINCT_METAMODELS [message #698274 is a reply to message #696322] |
Tue, 19 July 2011 07:33 |
|
Victor,
DistinctEcoreSimilarityChecker is a subclass of StatisticBasedSimilarityChecker. The one and only difference is that DistinctEcoreSimilarityChecker will ensure that the EClass of both compared objects are the same before going to the statistics checks.
What that means is that DistinctEcoreSimilarityChecker checks that the metamodels of the compared objects are _the same_ and there lies the misnaming.
So if MatchOptions.OPTION_DISTINCT_METAMODELS is "true" then we must _not_ use DistinctEcoreSimilarityChecker : it would always return false (since the EClasses are different).
The javadocs are right, the only misleading thing here is that DistinctEcoreSimilarityChecker is misnamed and should be named something along the lines of "SameMetamodelSimilarityChecker".
Laurent Goubet
Obeo
|
|
|
Re: [EMF Compare] Usage of MatchOptions.OPTION_DISTINCT_METAMODELS [message #699389 is a reply to message #698274] |
Thu, 21 July 2011 12:49 |
Eclipse User |
|
|
|
Originally posted by:
Laurent,
things are crystal-clear to me now, thanks for the clarification!
Víctor
Laurent Goubet escribió:
> Victor,
>
> DistinctEcoreSimilarityChecker is a subclass of
> StatisticBasedSimilarityChecker. The one and only difference is that
> DistinctEcoreSimilarityChecker will ensure that the EClass of both
> compared objects are the same before going to the statistics checks.
>
> What that means is that DistinctEcoreSimilarityChecker checks that the
> metamodels of the compared objects are _the same_ and there lies the
> misnaming.
>
> So if MatchOptions.OPTION_DISTINCT_METAMODELS is "true" then we must
> _not_ use DistinctEcoreSimilarityChecker : it would always return false
> (since the EClasses are different).
>
> The javadocs are right, the only misleading thing here is that
> DistinctEcoreSimilarityChecker is misnamed and should be named something
> along the lines of "SameMetamodelSimilarityChecker".
>
> Laurent Goubet
> Obeo
|
|
|
Powered by
FUDForum. Page generated in 0.04472 seconds