Community
Participate
Working Groups
Build Identifier: 20100603-0907 The two metamodel elements EModelElement and EGenericType lacks their inheritance to EObject. Former (2.5, 2.4) Ecore meta models contain the missing inheritances to EObject. Reproducible: Always Steps to Reproduce: 1. Open the model Ecore.ecore from (inside) bundle org.eclipse.emf.ecore_2.6.0.v20100607-0756.jar and check it. 2. Try to access the method eClass() on xtend instances of EStructuralFeature. 3.
Yes, that's an intentional change to avoid generating reflective eInvoke calls to EObject's operations. You'll have to learn to live with it. All models implicitly inherit from EObject anyway, so no framework shouldn't be requiring explicit inheritance.
(In reply to comment #1) > Yes, that's an intentional change to avoid generating reflective eInvoke calls > to EObject's operations. You'll have to learn to live with it. All models > implicitly inherit from EObject anyway, so no framework shouldn't be requiring > explicit inheritance. Ed, thanks for your quick response! Is there any documentation to understand the changes and how to live with it? For me it looks strange: when I access the EObejcts feature on any item (f.e. eClass()) progammatically, it works, when I try to access it via emf meta model - the features are missing. Especially via MWE there are at least two opportunities to point to the metamodel: * org.eclipse.xtend.typesystem.emf.EmfMetaModel.metaModelPackage * org.eclipse.xtend.typesystem.emf.EmfMetaModel.metaModelFile The first gives xtend/xpand/... the possibility to use the EObjects features, whereas the second denies it. It seems a little bit inconsistently to me. If the inheritance (as known as an "is-a" relationship) to EObject comes in implicitly, then this means that an object of a subclass (f.e. EModelElement) can be used wherever an object of the superclass (EObject) can be used. So the current behavior is quiet different to Java, where the src code contains the inheritance relationiships (via "extends") explicitly (of cause). Regards, Matthias
Xpand/Xtend should assume that all EMF modeled instances support EObject regardless of whether that's explicit in the hierarchy. Think of this as very similar to implicitly extending java.lang.Object. I'm really not sure what else to say. You might ask the xpand/extend folks about how to use EObject's API even for models that don't explicitly extend it, which I expect is the case for most models.
