eclipse-ocl-bot
commented
2 hours ago By Ed Willink on Oct 26, 2014 05:22
(In reply to Ed Willink from comment #0)
To support this we must introduce a UML-IdResolver which requires an ability to identify the user's technology space at the moment a MetaModelManager is created.
Yes, but while it is appropriate to impose one normalized pivot representation on all meta-models, it is not appropriate to impose just one technology space.
Where asEcoreObject seemed like an adequate way to restore legacy representation, the need for different UML representations shows that we need something more.
But even in the UML world, we may want OMG UML, with unbounded numerics, or Eclipse UML2, with '32 bit' integers and potentially both in the same application. We need to facilitate a custom IdResolver to define a custom technology space for value representations.
The IdResolver:MetaModelManager relationship must be N:1 not 1:1. Ideally, the MetaModelManager has no ability to navigate to an IdResolver at all.
Since MetaModelManger is fading away in favour of a CompleteModel, this API evolution seems like a good time to accommodate this change. Doing it directly on the current code will just incur double development costs.
| --- | --- | | Bugzilla Link | 448470 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Oct 23, 2014 07:16 EDT | | Modified | Feb 01, 2015 07:23 EDT | | Blocks | 447557 | | Reporter | Ed Willink |
Description
Bug 447567 identifies a problem with a UML evaluation that navigates from an EnumerationLiteral.
An EnumerationLiteral may be produced during OCL parsing and so needs to have a 'pivot' value. But it may be a UML model element or an Ecore 'model element' that isn't even an EObject.
The current philosophy is that any evaluation value for which Java equals is unuseable must be boxed during OCL evaluation as an OCLValue and unboxed when returned to the user. EnumerationLiteralId should therefore be an OCLValue since it has 'equal' UML and Ecore variants.
Creation of boxed values can be avoided when their unboxed instances are unique. A UML EnumerationLiteral should be unique, unless a *.uml is loaded dynamically as well as the Java Ecore equivalent; surely an unrecoverable disaster? An Ecore EEnumLiteral may not be unique since ;equal' Enumerators may exist independently.
If the IdResolver is responsible for boxing/unboxing decisions the UML-IdResolver can use unboxed EnumerationLiterals, while the Ecore-IdResolver and Pivot-IdResolver use boxed.
In order to avoid the potential confusion between a boxed value from a EnumerationLiteralExp and an unboxed value from a PropertyCallExp, EnumerationLiteralExp should give the IdResolver an opportunity to unbox the Pivot EnumerationLiteralId.
Similarly boxing of Type can be avoided, which should fix the EvaluateNameVisibilityTest4.test_implicit_source failure when using the code generator caused by a computed Set{Integer} failing to compare equal to literal Set{Integer}.
To support this we must introduce a UML-IdResolver which requires an ability to identify the user's technology space at the moment a MetaModelManager is created. This will avoid some magic UML-specific code in the communal PivotIdResolver.