Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] QVT13-48 allInstances() needs clarification

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"

Discussion on "Unspecified handling of imports without access/extends " will be continued in https://bugs.eclipse.org/bugs/show_bug.cgi?id=468367 "Implicit import by extends in combination with multiple modules per unit".




_______________________________________________
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



Back to the top