Re: [qvto-dev] Model extents for Operational Mappings

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

If we are agreed, this can certainly be piggy-backed on 13103 which is still under preview.

But before addressing the piggy-back can we agree on whether the current proposed resolution is a useful step forward, even if not the solution to all the problems?

My feeling is that as with traceability, I am looking for the 8.1.x sub-clause to give me an overview of the principles of the concept so that I can check that 8.2.x provides consistent elaboration. "Extent" is not even mentioned in 8.1 and hardly anywhere before 8.1 either.

The specific text in 8.2.1.16 seems like a classic bit of gibberish that I have always skipped over when trying to discover some meaning.

Apart from providing an ability to write a confusing specification, what is the purpose of an extent?

To me it just enables containerless EObjects to be put into a suitable Resource. Apart from the root of the intended output tree such containerless objects are all the result of bugs.

Ah! An extent could also provide limited search scope for allInstances(), but we have no syntax.

It seems perfectly sensible that a transformation has many ins, outs, inouts, all of which are typed by a TypedModel and bound, not necessarily uniquely, to Resources by the launch configuration. (So I see a one-to-one Resource to extent correspondence. If two mapping parameters are bound to the same one Resource they share the same on extent.)

When I write a transformation I want to specify which TypedModel I am dealing with and in main() I to explicitly access model parameters. Thereafter I expect sub-trees to passed to nested mappings, so the nestesd mappings use the TypedModel of the sub-tree; no need for any user specification at all.

Is there an example that demonstrates the need for Map[pingParameter extent declarations?

[Is it illegal to have a mapping parameter named 'pre'?!]

    Regards

        Ed Willink

On 04/02/2014 16:51, Adolfo Sánchez-Barbudo Herrera wrote:

Hi Christopher,

With respect to your concerns about mapping operations.

* Some thoughts*

The abstract syntax of MappingParameter is clear with respect to the model extent. Again the idea of "created object" is mentioned:

"Should be explicitly provided when there is an ambiguity on the

extent to own the potential created element corresponding to this parameter"

- OperationalMappings mention that the "out" parameters are instantiated when they are null. Since no instantiation occurs in an in/inout parameter, this means that specifying an extent on an in/inout parameter should probably be illegal. 

- What´s the point of providing a model extent to an in/inout parameter if no instantiation occurs?. The "extent inference rules" look like a messy type disambiguation based on model types. Two options here

1) model extents to in/inout parameters make sense. I don´t have a use case, but somebody could argue that the following is required:

mapping X::mapping(in a: Y@model1, in b : Y@model 2): Z;

So that we ensure that we are properly passing different model elements belonging to different model extents. Can this be checked at compile time (probably not without data dependency analysis)? Should this be checked at runtime instead ?

2) model extents to in/inout parameters DON'T make sense. Provided the meaning which is given to this @modelExtent concept across the specification, this would be my preference.

- In any case, the section needs to be reworked/clarified.

* A proposal *

This is the proposal for the second interpretation above, to make the specification clearer:

In 8.2.1.16, 

In associations subsection:

Replace:

"The extent of the mapping parameter. If not provided, the extent is inferred by inspecting the model types of the transformation. See the inference rules below. Should be explicitly provided when there is an ambiguity on the extent to own the potential created element corresponding to this parameter."

by

"The extent of an out mapping parameter. If not provided, the extent is inferred by inspecting the model parameters of the transformation. It should be explicitly provided when there is an ambiguity on the extent to own the potential created element corresponding to this parameter."

In constraints subsection.

An in/inout mapping parameter can´t specify a model extent:

context MappingParameter

inv: (kind = DirectionKind::_in or kind = DirectionKind::inout) implies extent->isEmpty()

In "Extent inference rule for mapping parameters" subsection:

Remove the  whole subsection.

In notation subsection:

replace:

mapping X::foo(inout Y@dest1) : Y@dest2;

by:

mapping X::foo(inout a : Y, out b : Y@dest1) : Y@dest2;

Ed, should we open a new OMG issue or just attach this or any other resolution to issue 13103 ?

Cheers,

Adolfo.

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

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7058 - Release Date: 02/03/14