Home » Modeling » QVT-OML » For QVT-O EObject seems not to be supertype of EModelElement
| For QVT-O EObject seems not to be supertype of EModelElement [message #990583] |
Thu, 13 December 2012 09:54  |
 Dietrich Travkin
Messages: 13
Registered: July 2009 |
Junior Member |
|
|
Hello,
in my QVT-O transformation I am using Ecore as one of several model types.
modeltype Ecore uses ecore('http://www.eclipse.org/emf/2002/Ecore');
In my mapping operations I rely on the fact that EObject is the supertype of all EMF model elements. But the QVT-O editor seems not to know that EObject is the supertype of all EMF model elements.
Using the Metamodel Explorer, I found out that the registered ecore package (http://www.eclipse.org/emf/2002/Ecore) defines the classes EObject and EModelElement, but EModelElement has no supertypes according to this model and, thus, seems not to be subtype of EObject.
Consequently, in my mapping operations like the following ones the signatures seem not to be complient to each other. Changing the result types from EClass and EOperation to EObject makes the signatures complient, but that's not what I want.
mapping MyElement::myElementToEcoreElement() : EObject
disjuncts MySpecialElementA::elementA2EClass,
MySpecialElementB::elementB2EOperation {}
mapping MySpecialElementA::elementA2EClass() : EClass {...}
mapping MySpecialElementB::elementB2EOperation () : EOperation {...}
Are there any suggestions how to cope with this issue? Should I better use EModelElement as the most general supertype for all model elements and as result type of my mapping operation myElementToEcoreElement or is there a better solution?
Thanks in advance,
Dietrich
|
|
|
| Re: For QVT-O EObject seems not to be supertype of EModelElement [message #990721 is a reply to message #990583] |
Thu, 13 December 2012 16:32  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
See
http://www.eclipse.org/forums/index.php/m/838655/?srch=oclAsType#msg_838655
Regards
Ed Willink
On 13/12/2012 16:21, Dietrich Travkin wrote:
> Hello,
>
> in my QVT-O transformation I am using Ecore as one of several model
> types.
>
> modeltype Ecore uses ecore('http://www.eclipse.org/emf/2002/Ecore');
>
> In my mapping operations I rely on the fact that EObject is the
> supertype of all EMF model elements. But the QVT-O editor seems not to
> know that EObject is the supertype of all EMF model elements.
>
> Using the Metamodel Explorer, I found out that the registered ecore
> package (http://www.eclipse.org/emf/2002/Ecore) defines the classes
> EObject and EModelElement, but EModelElement has no supertypes
> according to this model and, thus, seems not to be subtype of EObject.
>
> Consequently, in my mapping operations like the following ones the
> signatures seem not to be complient to each other. Changing the result
> types from EClass and EOperation to EObject makes the signatures
> complient, but that's not what I want.
>
>
> mapping MyElement::myElementToEcoreElement() : EObject
> disjuncts MySpecialElementA::elementA2EClass,
> MySpecialElementB::elementB2EOperation {}
>
> mapping MySpecialElementA::elementA2EClass() : EClass {...}
>
> mapping MySpecialElementB::elementB2EOperation () : EOperation {...}
>
>
> Are there any suggestions how to cope with this issue? Should I better
> use EModelElement as the most general supertype for all model elements
> and as result type of my mapping operation myElementToEcoreElement or
> is there a better solution?
>
> Thanks in advance,
> Dietrich
|
|
| |
| Re: For QVT-O EObject seems not to be supertype of EModelElement [message #990823 is a reply to message #990803] |
Fri, 14 December 2012 11:02 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi
Sorry, I read EObject not supertype, and gave the usual answer.
If you are using the Ecore meta-model then EObject is a superclass.
If you are using the compiled Java for the Ecore meta-model EObject is a
secret superclass.
Since you refer to EObject rather than ECore::EObject, I suspect that
you are therefore using the compiled Java.
So try Ecore::, otherwise use EModelElement which is not secret.
Regards
Ed Willink
On 14/12/2012 10:34, Dietrich Travkin wrote:
> Hello Ed,
>
> I don't see, how the following helper/query operation can help me with
> my problem.
>
>
> query OclAny::equalsType(other : OclAny) : Boolean
> {
> return self.oclAsType(Ecore::EObject).eClass() =
> other.oclAsType(Ecore::EObject).eClass()
> }
>
>
> The type conformance checking in my example is done by the QVT-O
> editor (and during execution by the engine), which tells me that the
> signatures of my mapping operations have non-conformant signatures.
> Thus, if I understand that correct, I would have to overwrite some
> operations from the standard library to ensure that oclIsKindOf(<some
> EObject>) is true for all elements. Or do you have something different
> in mind?
>
> Thanks,
> Dietrich
|
|
| | | |
Goto Forum:
Current Time: Fri Apr 19 13:25:13 GMT 2024
Powered by FUDForum. Page generated in 0.02916 seconds |
] 
Search
Help
Register
Login
Home
