[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [qvto-dev] model extents for clone/deepClone
|
Hi Ed,
My point about current issue 13103 issue is that it tries to also apply
model extents when updating objects, when the specification largely
tends to relate them just when objects are created. Also changing
residence of already created objects looks dangerous.
Is there any reason/use case which support current issue 13103 resolution ?
ModelExtent bits has a clear intention: give an initial residence to
created objects. This avoids orphan objects which can't be available
from the transformation caller (for instance to do a proper model
serialization). Going further than this simple conception is a bad idea,
in my opinion.
The callee only says where the object initially resides, the caller will
probably assign the created objects to the proper container. "where
resides" is just a transformation parameter, which the transformation
caller will later provide when executing a transformation.
[No thoughts about implications with QVT relations, but considering QVTo
in isolation this makes sense]
Regards,
Adolfo.
On 05/02/2014 11:06, Ed Willink wrote:
Hi
Yes, I agree with Adolfo that the extent inference text is rubbish.
IMHO, for QVTo in isolation, it the caller's responsibility to bind
arguments to extents not the callee's responsibility to bind parameters.
However given the requirement that a MappingOperation has a one-to-one
correspondence with a QVT Relation, this may not be possible without
declaration-time domain bindings. But QVT Relations don't seem to
support multiple parameters per domain, so I think we have at least a
couple of fairy stories to disentangle before we can make sense of it all.
As I observed earlier I want to see an 8.1.x sub-clause that outlines
the utility of extents.
Voting on ballot 3 started at 06:00 GMT so it is now a bit late to
piggy-back new material on 13103, but we can still correct errors or
withdraw it altogether.
I think 13103 is a step forward, so I'll raise a new Issue to properly
specify extents.
Regards
Ed
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
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