Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » QVT-OML » Wrong execution order in inheriting mapping operations?
Wrong execution order in inheriting mapping operations? [message #991534] Wed, 19 December 2012 17:14 Go to next message
Dietrich Travkin is currently offline Dietrich TravkinFriend
Messages: 13
Registered: July 2009
Junior Member
Hello,

I'm using some mapping operations that inherit from another mapping operation. The abstract mapping operation defines init and end phases/sections, but these are executed after the population phase of the inheriting mapping operations. Is that a bug or is this the desired behavior? I think, this is a bug.

Here is an example:

abstract mapping DesignElement::designElement2EModelElement() : EModelElement
{
	init
	{
		// do something
		result := ...
	}
		
	end
	{
		// do something
	}
}

mapping Type::type2EcoreElements() : EClass
	inherits DesignElement::designElement2EModelElement
{
	name := self.name;
	// do something more
}


When executing the type2EcoreElements mapping operation, the name attribute is set before the init section of the designElement2EModelElement mapping operation is executed. Thus, the assignement "result := ..." results in a thrown exception, since the result object is already created when the assignment is executed.

I think, the init section of designElement2EModelElement has to be executed before the population phase of type2EcoreElements begins.

Another problems is that the order of execution is beginning with the most special mapping operation. I think it has to be the other way around so that specialized operations can reuse results of previously executed inherited operations.

Am I wrong?

Best regards,
Dietrich
Re: Wrong execution order in inheriting mapping operations? [message #994540 is a reply to message #991534] Thu, 27 December 2012 16:18 Go to previous messageGo to next message
Fabio L. S. is currently offline Fabio L. S.Friend
Messages: 15
Registered: July 2010
Location: Brazil
Junior Member
Hi Dietrich;

Strange as it may seem, this is not a bug. It is how it is specified in QVT (see page 93 of the QVT 1.1 specification). I also think it is not right... I wrote a text discussing how it works and how I think it *should* work in http://www.levysiqueira.com.br/2012/06/inheritance-in-qvto/

Regards;


Fabio Levy Siqueira
Re: Wrong execution order in inheriting mapping operations? [message #995140 is a reply to message #994540] Sat, 29 December 2012 07:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Fabio

Please raise this and other related issues as OMG issues at
http://www.omg.org/report_issue.htm.

There may not appear to be a great deal of response, but there are some
of us working to establish a more modeled and consistent exposition of
the QVT specification.

Carefully considered critiques, and better still corrections, are very
helpful in clarifying what the specification should actually say.

Regards

Ed Willink


On 27/12/2012 16:18, Fabio L. S. wrote:
> Hi Dietrich;
>
> Strange as it may seem, this is not a bug. It is how it is specified
> in QVT (see page 93 of the QVT 1.1 specification). I also think it is
> not right... I wrote a text discussing how it works and how I think it
> *should* work in
> http://www.levysiqueira.com.br/2012/06/inheritance-in-qvto/
>
> Regards;
Re: Wrong execution order in inheriting mapping operations? [message #996347 is a reply to message #991534] Tue, 01 January 2013 21:33 Go to previous messageGo to next message
Christopher Gerking is currently offline Christopher GerkingFriend
Messages: 115
Registered: April 2011
Senior Member
Hi Dietrich,

are you sure that QVTo actually executes the population section first? That should not be the case. According to the spec, the correct behavior would be the following:


  1. Execute the so called "implicit instantiation section" (spec p. 93) of type2EcoreElements(), which creates an instance of EClass as result.
  2. Execute the init section of the inherited mapping designElement2EModelElement(), which creates another return value, which should override the previously created EClass.
  3. Execute the end section of designElement2EModelElement().
  4. Execute the population section of type2EcoreElements(), which sets the 'name' attribute of the result.


Hence, your scenario is special since you create multiple result values. I tried to reproduce the problem, but there is no exception in my case. However, the problem seems to be that the 'name' attribute is never set effectively. I suppose this is caused by a problem with the second result value failing to override the initial EClass result correctly. This could be related to the following bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=388325, which is currently about to be fixed.

Could the exception be caused by the actual value that is assigned to the result? What is the type of the assigned value? If it is not a subtype of EClass, a runtime exception is unavoidable.

Quote:
Another problems is that the order of execution is beginning with the most special mapping operation. I think it has to be the other way around so that specialized operations can reuse results of previously executed inherited operations.
Talking about the "order of execution", we must distinguish the different sections:
with respect to the population section, QVTo actually begins with the most general inherited mapping. With respect to the "implicit instantiation section", it must start with the most special mapping, because an inherited mapping might not know which concrete type it should instantiate as result. Only the most specific mapping is guaranteed to refer to the concrete type, hence the instantiation must begin there. With respect to the init section, I agree that a different order might be a better solution than the one currently described in the spec.
Re: Wrong execution order in inheriting mapping operations? [message #996532 is a reply to message #996347] Wed, 02 January 2013 10:03 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

It seems that the semantics need to be sorted out here.

I take the view, not specified, that a transformation language should do
as much as possible and that a smart implementation may eliminate the
associated redundancy. Thus all actions at all levels of
inheritance/refinement should occur. The created object has only one
actual concrete type so all inherited actions should respect this type.

In principle this could be achieved by some rewrite rules that defined
the appropriate creation of a flat construction for the one and only
concrete type. Once viewed as a flat construction, most-derived actions
first seems obvious. Local variables are permitted.

Overridden initialization may be eliminated if the redundant
initialization is side-effect free.

In order to modularize construction and re-use inherited support in a
practical implementation, it may be necessary to pass the concrete type
to the inherited constructors. Since QVTo is interpreted, synthesizing
the flat construction may be easier.

Christopher: would you like to take a shot at a clear exposition of the
semantics so that we can see whether Mariano Belaunde thinks it is sensible?

Regards

Ed Willink


On 01/01/2013 21:34, Christopher G. wrote:
> Hi Dietrich,
>
> are you sure that QVTo actually executes the population section first?
> That should not be the case. According to the spec, the correct
> behavior would be the following:
>
>
> Execute the so called "implicit instantiation section" (spec p. 93) of
> type2EcoreElements(), which creates an instance of EClass as result.
> Execute the init section of the inherited mapping
> designElement2EModelElement(), which creates another return value,
> which should override the previously created EClass.
> Execute the end section of designElement2EModelElement().
> Execute the population section of type2EcoreElements(), which sets the
> 'name' attribute of the result.
>
>
> Hence, your scenario is special since you create multiple result
> values. I tried to reproduce the problem, but there is no exception in
> my case. However, the problem seems to be that the 'name' attribute is
> never set effectively. I suppose this is caused by a problem with the
> second result value failing to override the initial EClass result
> correctly. This could be related to the following bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=388325, which is
> currently about to be fixed.
>
> Could the exception be caused by the actual value that is assigned to
> the result? What is the type of the assigned value? If it is not a
> subtype of EClass, a runtime exception is unavoidable.
> Quote:
>> Another problems is that the order of execution is beginning with the
>> most special mapping operation. I think it has to be the other way
>> around so that specialized operations can reuse results of previously
>> executed inherited operations.
> Talking about the "order of execution", we must distinguish the
> different sections:
> with respect to the population section, QVTo actually begins with the
> most general inherited mapping. With respect to the "implicit
> instantiation section", it must start with the most special mapping,
> because an inherited mapping might not know which concrete type it
> should instantiate as result. Only the most specific mapping is
> guaranteed to refer to the concrete type, hence the instantiation must
> begin there. With respect to the init section, I agree that a
> different order might be a better solution than the one currently
> described in the spec.
Re: Wrong execution order in inheriting mapping operations? [message #996722 is a reply to message #996532] Wed, 02 January 2013 19:14 Go to previous messageGo to next message
Fabio L. S. is currently offline Fabio L. S.Friend
Messages: 15
Registered: July 2010
Location: Brazil
Junior Member
Sorry for my wrong answer. My discomfort with the mapping inheritance semantics made me read what I wanted to read... Christopher is right about how the code posted should work.

Anyhow, the problem with the "execution order" is that all the parent (inherited) mapping is completely executed after the init and implicit instantiation section of the inheriting mapping. Thus, not only the order of init section is strange. The populate section, end section, when clause, and where clause have a strange order. What may be even more confusing, when the "when" section of the parent mapping does not hold, the Eclipse QVTo does not execute the parent mapping but continues normally with the execution of the inheriting mapping. I think this is absurdly wrong, but the OMG specification does not explain what should be done in this situation. Therefore, the Eclipse QVTo implementation is not incorrect.

I know it is not the correct place to discuss the problems in the OMG specification. As Ed suggested, I will raise an issue on OMG.

Again, sorry for my wrong answer.

Regards;


Fabio Levy Siqueira
Re: Wrong execution order in inheriting mapping operations? [message #997423 is a reply to message #996722] Mon, 07 January 2013 13:09 Go to previous messageGo to next message
Dietrich Travkin is currently offline Dietrich TravkinFriend
Messages: 13
Registered: July 2009
Junior Member
Hello all,

thank you for your helpful feedback.

Indeed, the execution order in the QVTo specification in some cases is quite confusing, which has to be reported to the OMG.

With Christopher's hints, I think, I understand the behavior in my special case better. I used the debugger to step through my transformation. The execution begins with the most special mapping operation (which is correct according to the spec., pages 77,78 PDF-pages 93,94). In my case, the transformation is more complex than the example above: I have another operation inheriting from type2EcoreElements() whose implicit instantiation section seems to be executed to create an EClass. After that the init section of the operation designElement2EModelElement() is executed which sets the result variable to an already existing EClass (I have an in-place transformation with an inout parameter). Since I don't know the concrete type of the result object in this abstract operation (in other inheriting operations it is another type than EClass), I don't cast the result object to EClass before assigning it to the result variable, thus, it is only known to be an EModelElement, but should be assignable to the result variable, since the result type of my designElement2EModelElement() is declared to be EModelElement which is a supertype of EClass. Though, the assignment
result := <the already existing EClass object>
or the implicit instantiation section of the operation designElement2EModelElement() leads to a QVTo runtime exception "Cannot instantiate type EModelElement". Thus, as Christopher reported, the exception could be raised due to the failure of overriding the initially created result (the EClass object created in the implicit instantiation section of type2EcoreElements()) in the init section of designElement2EModelElement().

However, I'm working on another solution to my problem and avoided the described situation be restructuring my transformation.

Best regards,
Dietrich
Re: Wrong execution order in inheriting mapping operations? [message #997425 is a reply to message #997423] Mon, 07 January 2013 13:22 Go to previous messageGo to next message
Dietrich Travkin is currently offline Dietrich TravkinFriend
Messages: 13
Registered: July 2009
Junior Member
P.S.:

Fabio, I had very similar expectations concerning the semantics of QVT-O as you described (http://www.levysiqueira.com.br/2012/06/inheritance-in-qvto/). But in one point, I think, Christopher is right. The implicit instantiation section has to be executed in the most special mapping operation before starting with the population sections, i.e. in your suggested semantics between the steps 4 and 5.
Re: Wrong execution order in inheriting mapping operations? [message #997426 is a reply to message #997423] Mon, 07 January 2013 13:23 Go to previous messageGo to next message
Dietrich Travkin is currently offline Dietrich TravkinFriend
Messages: 13
Registered: July 2009
Junior Member
No Message Body

[Updated on: Mon, 07 January 2013 13:28]

Report message to a moderator

Re: Wrong execution order in inheriting mapping operations? [message #997427 is a reply to message #997423] Mon, 07 January 2013 13:25 Go to previous message
Dietrich Travkin is currently offline Dietrich TravkinFriend
Messages: 13
Registered: July 2009
Junior Member
(sorry, I accidently sent my last message multiple times)

[Updated on: Mon, 07 January 2013 13:29]

Report message to a moderator

Previous Topic:"where" clause
Next Topic:Unsettable attribute, intrinsic defaults
Goto Forum:
  


Current Time: Fri Mar 29 15:01:59 GMT 2024

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

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

Back to the top