Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[qvto-dev] Issue 13103: element creation was: QVT 1.2 RTF Ballot 3 preview 2 
Hi Christopher,

[note: Victor Sanchez is the genuine issue sender]
This is interesting. Indeed, there is some more work needed. In any case, take into account that mappings *usually* use object expressions to populate the instantiated object (have a look to section 8.1.5). So 

mapping a(): X {
  name:= 'foo';
}

is a shorthand for :

mapping a() : result : X {
   population {
      object result : X {
         name:= 'foo';
      }
   }
}

After some study. My recollection is the following:
1. From my point of view, it's not clear *enough* what happens if an object already exists in an extent and a different one is provided in an object expression. 

2. Looking deeper into the specification: Section 8.2.1.24
/extent: References a model parameter where the object should reside in case it is instantiated. This is optional.
This lead to the conclusion that: the extent only applies when objects are instantiated, therefore no re-attachment or "change of residence" can take place. Those conclusions make sense to me: a) due to of the potential hazards which may arise when specifying model extents. b) I don't think that ObjectExp were conceived to "move" objects between extents or to remove them (there already is a Model::removeElement library operation) 

3. Therefore, with the aim of proposing some revised resolution:

In 8.2.1.24 ObjectExp add after the first paragraph
| Object creation , initialisation and residence are separate activities.
Object creation occurs when the referredObject has a null value; it is skipped if the referredObject variable 
references an existing object.
Object initialization always occurs, but may be trivial if the body is empty. When a new object is created, its residence will occur in the model parameter referred by the extent association. When the extent is omitted, object creation will normally result in an object without any residence; the residence will be established as soon as the created object is put at the target end of some composition relationship. When no object is created, no residence change occurs even though an extent is defined.
To not to mess up with the issue 13103 resolution, I'll create a different thread to discuss about Christopher concerns about mappings and/or clone/deepclone operations. 

Cheers,
Adolfo.

On 04/02/2014 10:37, Christopher Gerking wrote:

Hi Ed & Adolfo

I'm not yet convinced by the resolution for issue 13103: element creation and element attachment/detachment to/from an extent.

The proposed resolution targets ObjectExp only. Applying the "short form" to "long form" conversion rules, I expect that the proposed behavior holds for mappings as well. However, does this imply that elements are attached to an extent only on creation, and not reattached whenever they act as a mapping result? To clarify this hehavior, I already raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=425066 for Eclipse QVTo. Without reattaching, there seems to be no reasonable way of adding an element created inside a blackbox to an extent. Adolfo already pointed at the same issue: "there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time."

For the clone/deepclone operations, I just found out that Eclipse QVTo does not behave as described by Adolfo. It does not add the clones to the same extent as the original, but always obtains the proper "default" extent.

Do we require a new OMG issue?


Regards
Christopher



-----Ursprüngliche Nachricht-----
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Montag, 3. Februar 2014 20:02
An: qvt-rtf@xxxxxxx; QVTOML developer mailing list
Betreff: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2

Hi

Note that voting for Ballot 1 reballot is still open. Please vote.
Note that voting for Ballot 2 is still open. Please vote.

The second preview of QVT 1.2 RTF Ballot 3 is attached (with change bars since Preview 1).

Preview 30-Jan to 5-Feb
Voting 5-Feb to 19-Feb

Most of the 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).

I have managed to provide simple resolutions to two previously deferred issues.

Issue 12518 is substantially updated to include the redrawn Papyrus diagrams.

The provisional Ecore and UML models and Papyrus diagrams can be found in http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models

      Regards

          Ed Willink

Back to the top