Hi
Declaratively there is only the initial state so that is all that
can exist. For update transformations perhaps the 'output's on input
are available.
allInstances() is underspecified, in particular the extent from the
instances are discovered is unclear. Obviously we do not search the
web and break through firewalls to find instances lurking out there,
so it's not really ALL instances. A bit more subtly, we probably do
not include metamodels so that Class::allInstances() in a
transformation on the UML metamodel is not confused between its M1
and M2 Class instances. Whether intermediate instances are
discoverable is a design decision.
Regards
Ed
On 06/10/2015 11:31, Adolfo
Sanchez-Barbudo Herrera wrote:
Hi Folks,
It's interesting to have different (more than 2) thoughts on these
discussions, even better if they are not initially influenced by
other points of view. So I think that adding comments in the OMG
JIRA prior to here, is a good activity :)
My concerns about allInstances clarification issue are:
- A serious one: "For QVT,
allInstances() returns instances that form part of an input or
inout model before the transformation execution starts. These
instances are not modified by the execution of the
transformation. ". The second statement (required to
justify the proposed solution) breaks QVT, since in-place
transformations would not be allowed to remove (or "modify" as
stated) elements.
- More fundamental, I don't see any good/strong reason about why
allInstances can't be used on output elements. The argument that
X.allInstances call gives the same results in an OCL context,
shouldn't be translated to QVT, because they are simply different
languages with different properties and constraints. Therefore, in
a QVT context, allInstances might give different results.
NB: I don't think that the resolution is appropriate for QVTc/QVTr
neither. Allowing allInstances on types of in/inout models and not
allowing it to out models is simply unsound. Eclipse QVTo, ATL and
ETL indeed gives support to them. What I could agree on is that
allInstances usage on outputs might not be good in some (all?)
transformation scenarios, and therefore could be discouraged (it
doesn't mean prohibited) in declarative languages. I have no
evidence that allInstances might be required/needed in declarative
transformations, which doesn't mean that there might be a small
set of them which require this allInstances on outputs.
Similarly, I'm not sure why now you propose not to allow
allInstances on intermediate classes... Apparently, you seem to
see something wrong with allInstances, whose semantics seem quite
clear to me.
Regards,
Adolfo.
On 06/10/2015 10:52, Ed Willink
wrote:
Hi Sergey
Adolfo has been persuading me that the allInstances() resolution
is appropriate for QVTc/QVTr but not for QVTo, where OCL
semantics is only valid in ImperativeExpression-free subtrees.
Are you happy with the resolution, or just don't care since why
would users use it anyway?
I'm inclined to rewrite for QVTo as allInstances() search all
in/inout/out models, but not their metamodels and not
intermediate/transient/configuration models unless
non-transiently referenced from in/inout/out models.
Regards
Ed
On 06/10/2015 10:33, Sergey Boyko
wrote:
+1 for "Clarify deepclone
on Collections"
+1 for "Redundant argument
on matchIdentifier"
+1 for "allInstances()
needs clarification"
+1 for "Incorrect
navigation operator for LIst operations"
+1 for "NOP helper example
due to non-mutating List operation"
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
No virus
found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4435/10767 - Release
Date: 10/06/15
|