Hi Sergey,
Thanks for your comments, and specially for reviewing all the issues
resolutions.
Some comments in-line below about the modelExtent
On 06/02/2014 19:53, Sergey Boyko wrote:
Hi Adolfo,
I would add a few words on using of model extent in ObjectExp.
Technically (and EMF supports that) the containment hierarchy may be
split between several extents (Resources in terms of EMF). So even for
non-root object it sometimes may be necessary to explicitly specify
extent for the object being created.
But here, the model extent is the transformation model parameter. From
the point of view of the transformation, it doesn't care that a
complex containment hierarchy is actually split into different
different logical/physical resources. There won't be other model
extents if that were the case.
I like the idea of model extent of a "list of objects", because a
transformation modifies "pieces of a model", the modelExtent could
represent the whole resource (regardless it's split into different
logical/physical resources) or represent a part (sub-model) of it.
I think that Eclipse QVTo works in this way, doesn't it?. I'm
wondering what would happen if you pass a list of EObjects, which
belong to different logical/physical resources.
I like the idea to add 'Model::addElement(..)' operation. I think it's a
good companion for 'Model::removeElement()'.
Also I believe that implicit extent should be inferred for all cases
ObjectExp/InstantiationExp/MappingOperation, not least because of the
backward compatibility.
Currently, the spec only mentions MappingOperation (actually
MappingParameters) to infer model extents.
I see two alternative, providing we wanted the same behaviour for
every concept: ObjectExp, InstantiationExp, MappingParameter, cloning
library operations.
We have a trade-off dilema (+ means good point, - means bad point)
a) Always inferring a model extent (which also needs to be addressed
for clone/deepClone):
+ No orphan created model elements.
- Small performance overhead. Created objects always need to be placed
in the extent, even when they are usually assigned to another
containment reference afterwards.
+ Provided that a transformation didn't produced orphan model
elements, having ObjectExp/InstantiationExp/cloning library operations
be inferring model extents should not change previous transformations
results.
- In those transformation in which the model extent can't be inferred,
it could be annoying for model transformations writers to always have
to define the model extent when a new element is created (Note that
this happens in current specification, but "only" for MappingParameters)
b) Never inferring model extents
- Potential orphan model elements.
+ You can save an that small performance overhead.
- All those transformations with out MappingParameter which didn't
explicitly defined the model extent (because they were relying on the
model extent inference) might have different transformations results
(orphan model elements).
- The annoying issue I mentioned before doesn't happen.
Cheers,
Adolfo.
Regards,
Sergey.
On Wed, Feb 5, 2014 at 11:14 PM, Ed Willink <ed@xxxxxxxxxxxxx
<mailto:ed@xxxxxxxxxxxxx>> wrote:
Hi
8.2.1.16
Are we leaving this in an unsatisfactory state?
8.2.1.24
Your words allow a user specified extent to be ignored. Mine do not.
I don't understnad why your changes are better.
clone/deepclone.
We can certainly add a comment that the clone has no extent.
clone(Extent)/deepClone(__Extent)
This seems to be bloat, particularly given addElement, and has to be
duplicated for all the Collection/List/.... overloads.
Model::addElement(Element)
This seems like a useful addition, and makes clone(Extent)
unnecessary. But it needs stronger words regarding what happens to
an old extent.
Unfortunately Model is not defined anywhere in the specification! We
cannot add a method to it without defining it.
----
I think the lack of a Model specification clinches it. We're better
off not pretending to make this any better/worse.
I'll withdraw 13103 from Ballot 3, but that doesn't mean we have to
stop trying to resolve it now rather than one week before a QVT 1.3
deadline. Ping me in a week if I haven't responded to your
follow-up. Since we're trying to agree on words, a GoogleDoc might
be good for the hopefully converging consensus.
REgards
Ed
On 05/02/2014 18:29, Adolfo Sánchez-Barbudo Herrera wrote:
Hi All,
I endeavour to revise 13103 resolution (otherwise vote NO to
it). I can grasp a two claims by the issue sender:
1. ObjectExp::extent is an unnecessary overhead because they are
usually attached to a different container.
Indeed, it's usually an "overhead", but ... it's necessary
because it's the only way that the ObjectExp construct has to
attach created objects to an specific model extent (as root
elements).
2. There is not way to specify a model extent when using the
clone/deepClone library operations. Actually the specification
says nothing about where the cloned object resides (in the same
model extent of the clonned object? no residence ?)
I don't think that the resolution address the issues. Instead it
creates a new one, in particular with the claim:
"An explicit object residence may be established by specifying
the model
parameter for the required extent as the extent"
Both the resolution, and suggested revised text lead to the
interpretation that an object may change its residence even
though the object existed before (when referredObject != null).
This is a bad idea.
With respect to the extent, the specification vaguely (but
repeatedly) states that the residence is established upon
creation only. For instance see:
Section 8.2.1.16.
"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."
Section 8.2.1.24
"References a model parameter where the object should reside in
case it is instantiated. This is optional."
With all of this, in order to solve issue claim 2 and to avoid
the problem introduced by the current resolution, I propose a
new text for the issue resolution at the end of the email.
Regards,
Adolfo.
----
Resolution:
Indeed, specification doesn't clarify to which extent the cloned
elements belong to. There is no way to assign cloned elements to
an specific model extent neither.
Add a clone/deepclone version which accepts a model extent. For
completeness add a Model::addElement operation. To be aligned
with addElement description, sensibly add some text with the aim
to prevent calls to removeElement on an model parameter declared
as "in" model parameter.
Indeed, ObjectExp::extent is *usually* an overhead when they are
normally attached to a different container. However, unlike
MappingParameters, the extent is not stated to be inferred, so
if there is an overhead is because the transformation writer has
explicitly coded so (using the @modelExtent syntax).
Similarly to the clone/deepClone concern, this extent is
currently necessary because there is not other way to assign the
created element to a model extent.
Revised Text:
In 8.2.1.24 ObjectExp add after the first paragraph
Object creation, initialisation and residence are separate
activities.
Object creation occurs when the referredObject has a null value;
it is skipped if the referredObject variable
references an existing object.
Object initialization always occurs, but may be trivial if the
body is empty.
When a new object is created, its residence will occur in the
model parameter referred by the extent association. When the
extent is omitted, object creation will normally result in an object
without any residence; the residence will be established as soon
as the created object is put at the target end of
some composition relationship. When no object is created, no
residence change occurs even though an extent is defined.
In 8.3.4.10 add after the first paragraph
The element returned by this operation will not reside in any
model extent. It's a responsibility of the caller to proper
attach the created cloned element to a proper container.
Element::clone(Model modelExtent) : Element
Creates and returns a copy of a model element. Copy is done only
at first level (sub objects are not cloned). References to non
contained objects are copied only if the multiplicity
constraints are not violated.
The element returned by this operation will reside in the given
modelExtent. It's not allowed to provide a modelExtent declared
as an "in" transformation model parameter.
In 8.3.4.11 add after the first paragraph
The element returned by this operation will not reside in any
model extent. It's a responsibility of the caller to proper
attach the created cloned element to a proper container.
Element::deepclone(Model modelExtent) : Element
Creates and returns a deep copy of a model element. Copy is done
recursively on sub objects. References to non contained objects
are copied only if the multiplicity constraints are not violated.
The element returned by this operation will reside in the given
modelExtent. It's not allowed to provide a modelExtent declared
as an "in" transformation model parameter.
In 8.3.5.4. add after the first paragraph
It's not allowed to invoke this operation on a model extent
declared as an "in" transformation model parameter.
After 8.3.5.4 add the new Model operation
8.3.5.5 addElement
Model::addElement (Element element): OclVoid
Adds the given element to the modelExtent. This element will be
new element added to the existing root elements of the model extent.
It's not allowed to invoke this operation on a model extent
declared as an "in" transformation model parameter.
Disposition: Resolved
On 04/02/2014 11:27, Ed Willink wrote:
Hi Christopher
Issue 13103 was originally on my helpwanted list, but in the
absence of
any help, it was one where I thought I could take a shot at
it using my
intuition. At least it has now provoked some discussion, so
we can
discuss if
- I'm right and the proposed resolution stands
- it is easily corrected so we modify it
- we want a more prolonged discussion/research and the
resolution is
withdrawn.
No need for a new OMG issue while an existing one is still open.
In Eclipse terms, I interpret residence in an extent as
being locateable
by Resource.eAllContents(), so for any EObject the extent is
just
eObject.eResource() [or more pedantically to handle fragmented
resources: EcoreUtil.getRootContainer(__eObject).eResource()].
Objects created without any residence have a null
eResource() and so may
be lost.
In the case of mapping results, indeed the mapping has no
effect on
residence, but since the mapping result is often assigned to a
composition, that assignment changes the residence.
The issue addressed only ObjectExp, but if we should extend
it to
InstantiationExp then lets do so. Please suggest words.
Regards
Ed Willink
On 04/02/2014 10:37, Christopher Gerking wrote:
Hi Ed & Adolfo
I'm not yet convinced by the resolution for issue 13103:
element
creation and element attachment/detachment to/from an
extent.
The proposed resolution targets ObjectExp only. Applying
the "short
form" to "long form" conversion rules, I expect that the
proposed
behavior holds for mappings as well. However, does this
imply that
elements are attached to an extent only on creation, and not
reattached whenever they act as a mapping result? To
clarify this
hehavior, I already raised
https://bugs.eclipse.org/bugs/__show_bug.cgi?id=425066
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=425066>
for Eclipse QVTo.
Without reattaching, there seems to be no reasonable way
of adding an
element created inside a blackbox to an extent. Adolfo
already pointed
at the same issue: "there are other times when we need
to assign to an
extent some model elements that may have been created at
an unrelated
time."
For the clone/deepclone operations, I just found out
that Eclipse QVTo
does not behave as described by Adolfo. It does not add
the clones to
the same extent as the original, but always obtains the
proper
"default" extent.
Do we require a new OMG issue?
Regards
Christopher
-----Ursprüngliche Nachricht-----
Von: qvto-dev-bounces@xxxxxxxxxxx
<mailto:qvto-dev-bounces@xxxxxxxxxxx>
[mailto:qvto-dev-bounces@__eclipse.org
<mailto:qvto-dev-bounces@xxxxxxxxxxx>] Im Auftrag von Ed
Willink
Gesendet: Montag, 3. Februar 2014 20:02
An: qvt-rtf@xxxxxxx <mailto:qvt-rtf@xxxxxxx>; QVTOML
developer mailing list
Betreff: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2
Hi
Note that voting for Ballot 1 reballot is still open.
Please vote.
Note that voting for Ballot 2 is still open. Please vote.
The second preview of QVT 1.2 RTF Ballot 3 is attached
(with change
bars since Preview 1).
Preview 30-Jan to 5-Feb
Voting 5-Feb to 19-Feb
Most of the working material may be found at
http://svn.omg.org/repos/QVT/__trunk/Documents/TaskForces/1.2
<http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2>__.
Apply to
Juergen for a password, and beware of using SVN 1.8
tooling for the
1.4 server (1.7 seems fine).
I have managed to provide simple resolutions to two
previously
deferred issues.
Issue 12518 is substantially updated to include the
redrawn Papyrus
diagrams.
The provisional Ecore and UML models and Papyrus
diagrams can be found
in
http://svn.omg.org/repos/QVT/__trunk/Documents/__Specifications/1.2/Models
<http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models>
Regards
Ed Willink
-----
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
-----
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2014.0.4259 / Virus Database: 3684/7065 - Release Date:
02/05/14
_________________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx <mailto:qvto-dev@xxxxxxxxxxx>
https://dev.eclipse.org/__mailman/listinfo/qvto-dev
<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: 3697/7069 - Release Date: 02/06/14
