Hi
The problem is that the result of any blackbox mapping might already be
attached to some (other) extent. Thus, if we attach the mapping result
whenever returning from the blackbox code, we are likely to cause
residence changes (which we try to avoid in general). Therefore, we
would require a mechanism that keeps track of all the attached objects
and avoids any reattachments.
In my use case, the object created inside the blackbox mapping is
necessarily the root of a model extent. Now you might wonder why using
QVTo (and not plain Java) in this situation at all? Simply because the
respective transformation is imported via “access” from another real
QVTo transformation, and so the created object must necessarily be
packaged in the model extent.
However, maybe my use case is invalid nevertheless. Since the entire
transformation consists of just one blackbox mapping call, it might be a
better approach to make the entire OperationalTransformation a blackbox
Module (isBlackbox=true in the AST). The underlying Java implementation
should then allow direct read/write access to the model extents declared
at the QVTo level. Unfortunately, blackbox modules are currently
unsupported in Eclipse QVTo, see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427237 . Noteworthy, if
this is the right way to go, then model extents for blackbox mappings
are meaningless and should produce a compile error or warning.
Regards
Christopher
*Von:*Adolfo Sánchez-Barbudo Herrera [mailto:adolfosbh@xxxxxxxxx]
*Gesendet:* Dienstag, 4. Februar 2014 18:01
*An:* Christopher Gerking
*Cc:* Ed Willink; QVTOML developer mailing list
*Betreff:* Re: Issue 13103: element creation was: [qvto-dev] QVT 1.2 RTF
Ballot 3 preview 2
Hi Christopher,
I´m not sure I understand the problem.
If it´s black box mapping, the attachment could be done after the black
box code is performed
If it´s a normal qvto mapping, I´d expect to do the attachment after the
implicit instantiation phase (in case the out mapping parameters were
not already initialized). Nevertheless, I think that this (or any other
sensible approach) could also be explicitly stated in the specification.
In both cases, I´d expect the created elements to be assigned to some
containment feature at some point, otherwise we would have a lot of
created elements as root of the model extent,
Does this make sense ?
Cheers,
Adolfo.
On Tue, Feb 4, 2014 at 3:45 PM, Christopher Gerking
<christopher.gerking@xxxxxxxxxxxxxxxx
<mailto:christopher.gerking@xxxxxxxxxxxxxxxx>> wrote:
Hi Adolfo
First of all, sorry for the mistaken identity. Thanks for your
efforts nevertheless!
I agree with you that attaching elements to extents is probably
envisaged to happen only at instantiation time.
But then, we still lack some well-defined mechanism of attaching
objects created outside QVTo (e.g. inside Java blackbox code).
Regards
Christopher
-----Ursprüngliche Nachricht-----
Von: Adolfo Sanchez-Barbudo Herrera [mailto:adolfosbh@xxxxxxxxx
<mailto:adolfosbh@xxxxxxxxx>]
Gesendet: Dienstag, 4. Februar 2014 16:00
An: Christopher Gerking
Cc: Ed Willink; QVTOML developer mailing list
Betreff: Issue 13103: element creation was: [qvto-dev] 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=425066for 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>
> [mailto: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 <mailto: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 athttp://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
>
>
