Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] model extents for clone/deepClone 
Hi Ed,
I was replying to the two questions Christopher threw. Question 1 and 2, I think it should have been clear. I guess that we have had two many emails interchange in the last two days ;P. Apologies for that, I know you are quite busy.
We have had many emails, mixing different concerns. I've jsut sent to the RTF newsgroup (as you suggested) a hopefully well-structured reasoning about the issue 13103 resolution (leaving apart future enhancements). I propose the following alternative actions: 

a) My proposal doesn't make sense. Ignore it.
b) My proposal does make sense. Change the resolution on the fly.
c) My proposal has problems, but identifies other problems in your proposal. Withdrawn the resolution.
I believe it captures some (if not all) of the Christopher concerns. I think that he doesn't have access to that list, so to not to mess with a new email, I'll send the resolution privately to him. 

Regards,
Adolfo.
On 05/02/2014 17:13, Ed Willink wrote:

Hi Adolfo

[I'm not clear whether your Yes is to the first or second alternative.]

We seem a long way from agreement.

Do you want Issue 13103 withdrawn given that you don't have any simple
revision for it?

     Regards

         Ed

On 05/02/2014 16:46, Adolfo Sanchez-Barbudo Herrera wrote:

Hi Christopher,

My answers:
Question 1. Yes.
Question 2. Yes.
Same interpretation for every construct. Yes.

Issue 13103 have two claims:
- The attachment to the model extent is an overhead. This is true for
the majority of cases, but not always happen that a created object is
asigned to the corresponding container, therefore an attachment to an
model extent is required (you have mentioned real use cases).
- Clarification on what happen to the model elements created by a
clone/deepClone operation, highlighting the problem that if the same
extent is used, we have a problem if we want to clone objects from
"in" model extents.

I don't think that that issue 13103 helps to address the issue raised.
Even worse, from an "only attach on creation" interpretation changes
to "attach always" interpretation (including object updates).

Regardless Ed agrees or not, I'll try to warn RTF about Question 1.

Cheers,
Adolfo.

On 05/02/2014 16:18, Christopher Gerking wrote:

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
_______________________________________________
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

Back to the top