[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [qvto-dev] model extents for clone/deepClone
|
Hi
To me it seems as if we need to answer two basic questions:
1. Should elements be attached to extents only on creation, or whenever the code executes that is annotated with the extent?
* The 13103 resolution says: attach always in case of an object expression. What about mappings?
* The current spec vaguely says: attach only on creation.
* The current Eclipse implementation attaches only on creation (but also when cloning).
2. Should an implicit extent be inferred or not?
* The 13103 resolution says: not in case of an object expression. What about mappings?
* The current spec says: yes for mappings. What about object expressions and clone operations?
* The current Eclipse implementation does always infer an extent.
I hope that there is no need for the final resolution to distinguish between different language construct, e.g. the behavior for mappings should be consistent to the behavior for object expressions on both questions.
Regards
Christopher
-----Ursprüngliche Nachricht-----
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Mittwoch, 5. Februar 2014 12:53
An: QVTOML developer mailing list
Betreff: Re: [qvto-dev] model extents for clone/deepClone
Hi Adolfo
I really do not understand your point.
In the absence of any clarification, the current Issue 13103 goes to a vote.
Please correspond on the qvt-rtf list focussing primarily on what is wrong with the Issue 13103 revised text, not on a variety of other things that could be different.
This provides some chance of a sensible decision as to whether we can make some minor amendments to 13103 or just withdraw it so that the existing confusion is unchanged. Since the rest of the extent specification is suspect, no progress may be better than debateable progress.
Regards
Ed
On 05/02/2014 11:28, Adolfo Sanchez-Barbudo Herrera wrote:
> 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
>>
> _______________________________________________
> 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
