search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[pivot] self.oclAsType(ecore::EObject).eContainer() doesn't work #1549

Open eclipse-ocl-bot opened 1 month ago

eclipse-ocl-bot commented 1 month ago

| --- | --- | | Bugzilla Link | 469371 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 04, 2015 05:41 EDT | | Modified | Jun 04, 2015 07:17 EDT | | Depends on | 469375 | | Reporter | Ed Willink |

Description

self.oclAsType(ecore::EObject).eContainer()

for e.f. an EPackage gives

Incompatible source type: 'ecore::EPackage' for oclAsType(ecore::EObject)

Looks like metamodel schizophrenia.

When fixed, update the OCL FAQ at

https://wiki.eclipse.org/OCL/FAQ#Using_the_Pivot_OCL

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Jun 04, 2015 06:17

(In reply to Ed Willink from comment #0)

Incompatible source type: 'ecore::EPackage' for oclAsType(ecore::EObject)

Looks like metamodel schizophrenia.

No. It is the Helios change whereby EModelElement no longer has EObject as a modeled superclass; consequently any modeling tool denies the existence of EObject functionality.

The implementation of oclAsType() could be changed to allow conversion based on the underlying EClasifier.instanceClass when the modeled classes fail to conform, but it still doesn't work.

EObject.eAllOperations() does not include "eContents()", so the activation via eInvoke fails. But EcorePackage does define

EOperation EOBJECT___ECONTENTS = eINSTANCE.getEObject__EContents();

and EObject::eInvoke() does do

  case EcorePackage.EOBJECT___ECONTENTS:\
    return eContents();

so this begins to look like an EMF bug.

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Jun 04, 2015 06:29

(In reply to Ed Willink from comment #1)

(In reply to Ed Willink from comment #0) so this begins to look like an EMF bug.

Bug 469375

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Jun 04, 2015 06:56

(In reply to Ed Willink from comment #2)

so this begins to look like an EMF bug.

Bug 469375

a debateable bug/feature.

Even if it was fixed today, the fix would not provide backward compatibility for OCL.

If we allow oclAsType to cast to unmodeled underlying Java classes, then the self.oclAsType(ecore::EObject) cast is ok, and the self.oclAsType(ecore::EObject).eContainer() lookup is ok too.

Just need the getImplementation for the operation to return a ReflectiveOperation rather than an EInvokeOperation so that evaluation uses Java reflection to access the method rather than eInvoke().

eclipse-ocl-bot commented 1 month ago

By Ed Willink on Jun 04, 2015 07:17

(In reply to Ed Willink from comment #3)

If we allow oclAsType to cast to unmodeled underlying Java classes

This dubious pragmatism could be avoided by just getting round to supporting Java invocations.

self.'java:org.eclipse.emf.ecore.EObject'::eContainer()