Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] Issue 13103: element creation was: QVT 1.2 RTF Ballot 3 preview 2 
Hi Sergey,
Could you elaborate your reasoning about the prototype defined by a ModuleImport ?
What's the point of passing a ModelType rather than the ModelParameter. IMO the extended transformation needs the parameter, basically the modelExtent in which the created objects are placed. I guess that in many situations you can match/infer the modelParameter from the modelType. But in some cases you can't. See for example, the following: 


transformation ta(in a: A, out b : B)
-- Some mapping operations which creates elements in modelExtent b from elements of modelExtent a
We could be interested in extending that transformation with the following one: 

transformation tb(in a: A, out b1: B, out b2: B)

Two alternatives :

a) extends ta(A, B)  -- with model types
b) extends ta(a, b2) -- with model parameters

Thoughts ?

Cheers,
Adolfo.
On 06/02/2014 20:42, Sergey Boyko wrote:

Hi Adolfo,


On Wed, Feb 5, 2014 at 3:47 PM, Adolfo Sanchez-Barbudo Herrera
<adolfosbh@xxxxxxxxx <mailto:adolfosbh@xxxxxxxxx>> wrote:

    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.


Actually QVTo behaves with extents in extended/accessed transformations
exactly as you have described. Could you please specify use case when it
performs incorrectly.


    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


Specification is correct on this topic. ModuleImport defines prototype
while ModelParameter is a value (an instanceof ModelType) which is
passed on transformation's invocation.

Regards,
   Sergey.


    Cheers,
    Adolfo.

    On 05/02/2014 08:29, Christopher Gerking wrote:

        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
        <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
        <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.



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

Back to the top