eclipse-ocl-bot
commented
2 weeks ago By Ed Willink on Mar 19, 2018 13:53
If we use the not-an-instanceClass extra eSuperType workaround we add another supertype to all types.
If we move the instanceClass to a Java @extends comment annotation we save a supertype on every modelled type (e.g. save a XXXSwitch case.) but have a minor API compatibility in XXXTables through loss of the type.
IIRC inclusion/exclusion of Visitor/Visitable in the .ecore was a cannot-agree between me and Adolfo. Avoiding confusion for dynamic model usage and bloat for generated models clearly advocates excluding Visitable, Nameable, Pivotable, MorePivotable from the source .uml/*.ecore. Thy do not exuist in the dynamic model. They are manually added to the Java code by @extends comments.
| --- | --- | | Bugzilla Link | 532613 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Mar 19, 2018 12:27 EDT | | Modified | Mar 22, 2018 11:43 EDT | | See also | 532561 | | Reporter | Ed Willink |
Description
Bug 532561 reported that models that have a mix-in to define a Java interface class for the root model EClass cannot be used as the targets of a dynamic EMF model transformation; the Java interface is instantiated rather than DynamicEObjectImpl.
It seems unlikely that any of the fixes suggested in Bug 532561 will make it into EMF, so the models must change, in particular Pivot.ecore which forms the foundation for OCL and QVTd, yet cannot be a dynamic M2M target.
This requires that
the Nameable EClass be removed and its mixin applied by a manual Java comment annotation.
the Visitable class be similarly imposed possibly by a manual Java comment, possibly by upgrading the auto-generator. Alternatively the default "VisiableClasses" GenAnnotation can be rejuvenated to allow a bogus root class that has no mix-in and no visitability.
Ah! A fudge. If we have a bogus first mix-in without an instanceClass, the problematic mix-ins will be problematic only on the ignored second interface.