Community
Participate
Working Groups
The EMF changes making EObject inheritance less obvious require that MDT/OCL introduce a mechanism to exploit EObject. This will render the need to manipulate IMPLICIT_ROOT_CLASS obsolete. Suggest that xxx.oclAsType(ecore::EObject) give the intuitively obvious behaviour even though EObject may not appear to be a supertype of xxx in the meta-model. xxx.oclIsKindOf(ecore::EObject) should return false unless the inheritance of EObject is explicit in the meta-model. This then requires that a binding from ecore:: is established by the user. This is already done by the different Ecore/UML2 registry set-ups, and can be more explicit once the Model Registry is in place.
In https://bugs.eclipse.org/bugs/show_bug.cgi?id=202611#c3 Christian expressed surprise that eContents() could be used, and felt it unfortunate that EModelElement inherited from EObject. The EMF chnage is therefore in accord with convergence on the OCL standard. To avoid build failures CollectionsTest.test_valueOfOperationTypedByEEList_202611 has been commented out, with a FIXME. It needs re-instating in a legal fashion.
Created attachment 163457 [details] Reinstatement of suppressed test Attached sets IMPLICIT_ROOT_CLASS in order to make eContents() accessible. We therefore have a general workaround: eXXX usage now requires ParsingOptions.setOption(ocl.getEnvironment(), ParsingOptions.implicitRootClass(ocl.getEnvironment()), EcorePackage.Literals.EOBJECT); whether the meta-model inherits EObject or not.
Committed to CVS HEAD.
Closing
