[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [qvto-dev] model extents for clone/deepClone
|
Hi
I see no prospect of making progress until someone comes up with the
overview description of an extent, its purpose, its de/re/establishment.
I'm afraid that I must now concentrate on a traceability paper, so
cannot continue this correspondence this week.
Regards
Ed
On 05/02/2014 11:11, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed, Christopher,
If we agreed with the following statements:
a) An extent specification makes sense only when objects are created.
No an object can be re-extented.
b) A created object will always belong to a model extent.
No a created object may be without extent until assigned as the target
of a composition relationship.
c) Objects model extent can't change residence via model extent
specification. They need to manually be assigned to the proper
container (via containment references assignment or a library operation)
A new horror, calling a mapping operation that imposes a different
extent! Does it migrate?
I could recollect a joint Issue resolution towards this direction.
What Issue are you referring to?
If you see reason about why any of those statements should not be
true, please give me some lights with examples.
More details in the TL;DR version
Regards,
Adolfo.
----------- TL;DR---------------
Yes, it looks like Ed missed one of the emails explaining why the
issue 13103 resolution is not satisfying, IMO. Please have a look to
it (title: Issue 13103: element creation was: [qvto-dev] QVT 1.2 RTF
Ballot 3 preview 2). It also includes an revised resolution for the
issue.
No, changing residence of an object which already has got a residence
via this modelExtent specification is not good idea. IMO, it's
hazards-full language decision. Actually, I'm inclined to always make
an object have residence regardless when/how they are created.
MappingParameter (section 8.2.1.16) goes in this direction: if the
residence can't be inferred when it's not specified, an ambiguity
error needs to be thrown. Actually the specification could be improved
so this extent inference is statically computed (the extent is
mandatory in the AS) rather than dynamically computed at runtime.
IMO, things get simple and coherent when we see the model extent
specification whenever a object is CREATED/INSTANTIATED. In QVTo I
conceive 4 ways to create objects:
a) ObjectExp when the referredObject is null
b) In the implicit instantiation section of MappingOperations, when
out mapping parameters are null after the init section is executed.
c) Using InstantiationExp -> using the new keyword.
d) Using clone/deepClone library operations
QVTo specification says that you can explicitly especify the
@modelExtent for a), b), c). Nothing is said about d). In the three
cases are always related to "creating" objects, not when updating
them. Updating objects could take place in in a) and b) and
attaching/reattching to a different model extent should NOT take place.
I understand Ed's point since when you clone objects you will
*usually* attach them to another object via a compose association (aka
containment reference). However, Christopher case is valid and I don't
think that QVTo provides means to do it: There is not to a
Model::addElement(Element ) operation. Actually if it where pointless,
we should also consider why is useful for InstantiationExps
Another point is that what if a Model::addElement(Element) should have
been more convenient rather than the @modelExtent specification. The
@modelExtent looks like a more handful mean to do the same. We don't
neither want to break the specification to get rid of the @modelExtent
specification in favor of a Model::addElement(Element) library operation.
So if it were my duty, with respect to the clone/deepClone the
specification would change in the following way:
- In Element::clone/deepClone library operation, clarify that the
created element belong to the same model extent of object which is
created from.
- Add an Element::clone/deepClone(Model extent) operation.
This changes leads to the ideally situation in which in a m2m
transformation every object will always belong to a model extent.
On 05/02/2014 09:58, Christopher Gerking wrote:
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.
*Von:*qvto-dev-bounces@xxxxxxxxxxx
<mailto:qvto-dev-bounces@xxxxxxxxxxx>[mailto:qvto-dev-bounces@xxxxxxxxxxx]
*Im Auftrag von *Ed Willink
*Gesendet:* Mittwoch, 5. Februar 2014 09:47
*An:* QVTOML developer mailing list
*Betreff:* Re: [qvto-dev] model extents for clone/deepClone
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
*Von:*qvto-dev-bounces@xxxxxxxxxxx
<mailto:qvto-dev-bounces@xxxxxxxxxxx>[mailto:qvto-dev-bounces@xxxxxxxxxxx]
*Im Auftrag von *Ed Willink
*Gesendet:* Dienstag, 4. Februar 2014 18:54
*An:* QVTOML developer mailing list
*Betreff:* Re: [qvto-dev] model extents for clone/deepClone
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:
Hi Christopher,
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.
and optionally:
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
Cheers,
Adolfo.
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx <mailto:qvto-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2014.0.4259 / Virus Database: 3684/7058 - Release
Date: 02/03/14
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx <mailto:qvto-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2014.0.4259 / Virus Database: 3684/7062 - Release Date:
02/04/14
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx <mailto:qvto-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus found in this message.
Checked by AVG - www.avg.com <http://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
_______________________________________________
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