Hi
Ok. This gives rise to residence changes, which is basically ok for me.
But then we need to consistently revise also 8.2.1.16, which mentions “the potential created element” and therefore
gives the impression that the extent plays a role only on creation. The 8.2.1.16 revision proposed by Adolfo would be invalid then, because it makes the very same assumption that residence affects only the creation.
What about the extent inference rules? Should they apply only to mapping parameters? Not in case of object expressions
or clone/deepclone calls? Should they apply at all?
Regards
Christopher
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."
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Ed Willink
Gesendet: Mittwoch, 5. Februar 2014 10:17
An: QVTOML developer mailing list
Betreff: Re: [qvto-dev] model extents for clone/deepClone
HI
No. Read the proposed revised text for Issue 13103.
Regards
Ed
On 05/02/2014 09:02, Christopher Gerking wrote:
As Adolfo pointed out, the extent of an ObjectExp applies only if the object is actually instantiated (not just updated,
like in the cloning case).
Would you agree?3.
Hi
If the clone is to be root, then it probably occurs in main() which seems to have its own way of managing extents.
Otherwise an ObjectExp may assign the clone to its extent.
Regards
Ed
On 05/02/2014 08:40, Christopher Gerking wrote:
Hi again
What if the clone is meant to be the root of an extent? Then it does not participate in any containment.
Therefore, I think we do need to attach a clone to an extent. Again, I find the current Eclipse QVTo solution very practical,
which reuses the inference rules for mappings that do not specify an explicit extent.
Regards
Christopher
Hi
I see no point in a cloned object automatically belonging to any extent. The clone should become part of a Resource as soon as ity participates in a containment relationship.
The clone can be explicitly extented using an ObjectExp.
If the user neglects to provide an extent tough it's lost. If QVTo is kind, it could issue a warning, and possibly even put it in yet another Resource, or the trace model.
Regards
Ed
On 04/02/2014 17:12, Adolfo Sánchez-Barbudo Herrera wrote:
To be honest I´m not up to date with your/EclipseQVTo clone/deepClone discussions, but the specification should clearly state what happens when cloning objects. I only see a couple of alternatives:
1) They don´t belong to any modelExtent.
2) They belong to the same modelExtent of the cloned object.
3) They can explicitly belong to a model extent, for instance with some library operations:
a) Element::clone/deepClone(Model extent) : Element
b) Model::clone/deepCloneElement(Element element): Element
_______________________________________________
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
_______________________________________________
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/7062 - Release Date: 02/04/14
_______________________________________________
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/7062 - Release Date: 02/04/14