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.
