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
|