Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Dietrich Travkin is currently offline Dietrich Travkin
Messages: 11
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4045
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 #990803 is a reply to message #990721] Fri, 14 December 2012 10:34 Go to previous messageGo to next message
Dietrich Travkin is currently offline Dietrich Travkin
Messages: 11
Registered: July 2009
Junior Member
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
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 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4045
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
Re: For QVT-O EObject seems not to be supertype of EModelElement [message #991521 is a reply to message #990823] Wed, 19 December 2012 16:32 Go to previous messageGo to next message
Dietrich Travkin is currently offline Dietrich Travkin
Messages: 11
Registered: July 2009
Junior Member
Hi,

I'm using the Ecore meta-model, not the compiled Java for the Ecore meta-model (if I'm not misunderstanding something). But according to the metamodel explorer of the QVT plug-ins the class EModelElement has no supertypes, although the class EObject is visible. It seems, EObject is secretely a supertype of all other types (at least for QVT).

Now, I'm casting to EModelElement where necessary.

Regards,
Dietrich
Re: For QVT-O EObject seems not to be supertype of EModelElement [message #992285 is a reply to message #991521] Fri, 21 December 2012 09:28 Go to previous messageGo to next message
Dietrich Travkin is currently offline Dietrich Travkin
Messages: 11
Registered: July 2009
Junior Member
Hi,

in the meanwhile, I found the bug report where Ed Merks states that the inheritance relation to EObject will remain implicit, i.e. the relation will not be explicitly contained in the Ecore meta-model.

Bug report No 316894: https://bugs.eclipse.org/bugs/show_bug.cgi?id=316894

It seems, the QVT-O engine and editor have to cope with this.

Regards,
Dietrich
Re: For QVT-O EObject seems not to be supertype of EModelElement [message #992308 is a reply to message #992285] Fri, 21 December 2012 10:21 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4045
Registered: July 2009
Senior Member
Hi

In https://bugs.eclipse.org/bugs/show_bug.cgi?id=297011#c2 you'll find
the OCL impact and recognition that the change although irritating is
actually good.

Regards

Ed Willink

On 21/12/2012 09:28, Dietrich Travkin wrote:
> Hi,
>
> in the meanwhile, I found the bug report where Ed Merks states that
> the inheritance relation to EObject will remain implicit, i.e. the
> relation will not be explicitly contained in the Ecore meta-model.
>
> Bug report No 316894:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=316894
>
> It seems, the QVT-O engine and editor have to cope with this.
>
> Regards,
> Dietrich
Previous Topic:Acces QVT-O transformations from other folders or plug-ins
Next Topic:"where" clause
Goto Forum:
  


Current Time: Tue Sep 16 07:40:57 GMT 2014

Powered by FUDForum. Page generated in 0.02428 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software