| Re: [qvto-dev] Issue 13103: element creation was: QVT 1.2 RTF Ballot 3 preview 2 |
Hi Christopher,
When you compose transformations, the model extents are transferred, so the mapping operation of the corresponding extended/accessed transformation creates the element in the correct model extent. See QVT 1.1 example at the end of page 71. So basically, you shouldn't need to change the residence of the created object. To me, this makes sense.
Another point is that current Eclipse QVTo doesn't work as it should, but that's not a problem of the specification ;P.
Ah! Studying a little more on this respect. ModuleImport (Section 8.2.1.4) should probably refer to ModelParameter rather than ModelType. Obviously, the ModelType of the passed ModelParameter should be "compatible" to the the ModelType of the ModelParameter declared by the accessed/extended transformation. Definitely, somebody has really messed up, either the spec or me ;P
Cheers,
Adolfo.
On 05/02/2014 08:29, Christopher Gerking wrote:
*Von:*Adolfo Sánchez-Barbudo Herrera [mailto:adolfosbh@xxxxxxxxx]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
*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.