Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] QVT 1.2 RTF Ballot 1 preview 1
Hi,

About  "Issue 18363: Undefined semantics for unsatisfied "when" and "where" in inherited mappin" (http://www.omg.org/issues/qvt-rtf.open.html#Issue18363)

This issue is about clarifying the invocation semantics of inherited mappings. 
First of all I'm agree with proposed semantics of "when" and "where" and I think that it should be included to specification. Mentioned LSP is not applicable here. Looking on how the semantics of invocation of inherited mappings is defined it looks that semantics is defined incorrectly.

There are three places in the document where the behavior is declared:

a)  Section "8.1.12 Reuse Facilities for Mapping Operations"
    A mapping operation may inherit from another mapping operation. In terms of execution semantics the inherited mapping
is executed after the initialization section of the inheriting mapping. The example below illustrates the usage of mapping
inheritance.

b) Section "8.2.1.15 MappingOperation", paragraph "There are three reuse and composition facilities associated to mapping operations:"
  1. A mapping operation may inherit from another mapping operation. This means invoking the initialization section of the inherited operation after executing its own initialization section.

c) Section "8.2.1.15 MappingOperation", paragraph "Execution Semantics, Executing mappings that inherit from other mappings"
    A mapping that has inherited mappings invokes first its initialization section, including the implicit instantiation section,
and then invokes the inherited mappings. Invocation of the inherited mappings follows the “standard” invocation
semantics, except that the out parameters may now start with a non-null value, which would be the case if the out
parameter were changed in the initialization section of the inheriting mapping. Parameter compliance between the
inheriting mapping and the inherited mapping follows the compliance constraints between a caller and a callee.


So the specification states that inheriting mappings invokes first its initialization section, including the implicit instantiation section, and then invokes the inherited mappings including their's initialization section. In case when initialization section of inherited mapping contains assigment to result variable such behavior will result in that the mapping returns object differ than one stored in trace-record. This breaks fundamental property of mapping definition.

The problem is that the order of calls of initialization sections has been inverted. To be correct the order of calls should be the same as for the mappings population sections. In other words initialization section of inherited mappings should be invoked first, then initialization section of  inheriting mapping and then the implicit instantiation section.

Given the following mappings are defined as follows (pseudocode):
  maping a() {}
  maping b() {}
  maping c() inherits a {}
  maping d() inherits b, c {}

Then in case of mapping invocation
  map d()

The order of calls should be
  b()-when{}
  a()-when{}
  c()-when{}
  d()-when{}

  b()-init{}
  a()-init{}
  c()-init{}
  d()-init{}

  d()-implicitInstantiation_and_addToTrace
  b()-implicitInstantiation_and_addToTrace
  c()-implicitInstantiation_and_addToTrace
  a()-implicitInstantiation_and_addToTrace

  b()-population{}
  a()-population{}
  c()-population{}
  d()-population{}

  b()-where{}
  a()-where{}
  c()-where{}
  d()-where{}


Regards,
  Sergey.


On Tue, Dec 31, 2013 at 5:27 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi

The first preview of QVT 1.2 RTF Ballot 1 is attached.

Preview 1-Jan to 8-Jan
Voting 8-Jan to 22-Jan

The resolutions in this ballot are mostly the oldest (so mostly QVTc), or most controversial. QVTo-only reviewers may prefer to look at the No-Changes.

All working material may be found at http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4 server (1.7 seems fine).

Most of the resolutions for Ballot 2 and 3 can be found in QVT1.2RTFBallotAll.odt.

I do not feel confident enough to address the following so they will be deferred unless someone comes up with the bulk of a resolution proposal. i.e. discussion and editorial changes.

http://www.omg.org/issues/qvt-rtf.open.html#Issue12370
http://www.omg.org/issues/qvt-rtf.open.html#Issue13082
http://www.omg.org/issues/qvt-rtf.open.html#Issue13103
http://www.omg.org/issues/qvt-rtf.open.html#Issue13168
http://www.omg.org/issues/qvt-rtf.open.html#Issue13180
http://www.omg.org/issues/qvt-rtf.open.html#Issue15376
http://www.omg.org/issues/qvt-rtf.open.html#Issue15390
http://www.omg.org/issues/qvt-rtf.open.html#Issue17538
http://www.omg.org/issues/qvt-rtf.open.html#Issue18323
http://www.omg.org/issues/qvt-rtf.open.html#Issue18324
http://www.omg.org/issues/qvt-rtf.open.html#Issue18325
http://www.omg.org/issues/qvt-rtf.open.html#Issue18363

    Regards

        Ed Willink

On 28/12/2013 13:17, Ed Willink wrote:
Please reply to this email to confirm that you are able to participate in the ballots (and identify any resolutions you feel able to write).
No replies. I hope you're all enjoying a long break.

_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/qvto-dev


Back to the top