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