Hi
Trace records in Eclipse QVTo are produced by mapping executions only, regardless of disjuncts, blackbox, and the presence of an init section.
With respect to the recorded information please refer to class
org.eclipse.m2m.internal.qvt.oml.trace.TraceRecord.
It points to
·
the executing MappingOperation
·
the source/context object on which the mapping was executed
·
the passed parameter objects
·
and the result object.
The result is not necessarily unique. Eclipse QVTo doesn’t consider mutation of the inputs.
During your AMT talk, I got the impression that it’s not enough if a trace record refers to the executing mapping M. Since QVTo supports instantiation of transformations,
a trace record should refer to a mapping instance m:M. This allows a chain of transformation instances to share a common mapping M, but still execute distinct mapping instances m:M without erroneous reusing of the prior mapping results. Provided that this
is the case, a resolveIn(M) operation should also be executed in the scope of a particular m:M. These measures might indicate a resolution for
http://solitaire.omg.org/issues/task-force/QVT13-22,
because they allow any nested transformation instances to safely reuse the trace of the parent transformation instance, ensuring full traceability from the viewpoint of the
parent transformation, without bypassing necessary re-executions inside sub-transformations.
The trace is accessed
·
by all types of resolve operations
·
prior to a mapping execution in order to check if the source has already been mapped by that mapping (if so, the mapping won’t re-execute, basically
an implicit resolveoneIn)
·
by Sergey’s incremental update execution mode (https://bugs.eclipse.org/bugs/show_bug.cgi?id=463555,
since the trace doesn’t consider input mutations, I’m not sure how reliable it is: does it recognize “nested” changes to an input model, and actually re-execute all the necessary
parts?)
·
by the internal trace XML serialization
Kind regards
Christopher
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Ed Willink
Gesendet: Freitag, 9. Oktober 2015 11:16
An: qvto-dev@xxxxxxxxxxx
Betreff: Re: [qvto-dev] QVT13-69 List and Dict Class/DataType confusion
Hi Christopher
My interpretation of the current specification is that the phrasing was chosen in order to avoid some anticipated implementation problems. I think that the intent is to make the 'really good flow analyzer' really trivial.
Unfortunately the 'proprietary' motivation is obscured and so difficult to question.
Experience shows that these restrictions are often misguided.
In trying to make sense of this, it would be very helpful to me if you can provide a brief table of:
events that add information to the trace and what that information is
facilities that interrogate the trace and what they access
I would like to finish this resolution over the weekend and so provide a couple of further days for comments before the official preview starts on Wednesday.
So today would be really helpful for the table.
Regards
Ed Willink
On 09/10/2015 09:38, Christopher Gerking wrote:
Hi again
In general I like the approach of making all object creation visible to ‘resolve’. I consider this as a best practice, but also fairly optimistic to hardwire
into the specification.
The prohibition implies no ‘object’ instantiations and mapping calls inside a query/helper. However, the same applies to constructor invocations.
If we really want to restrict object creation to mappings, then a constructor/object instantiation for type A may be invoked only inside the init section of a
mapping with the same return type A, or some super type. In addition we must ensure that there is at most one runtime instantiation inside the init section, and that the instantiated object is eventually assigned to the ‘result’ variable.
There must be a really good control flow analyzer to ensure the above restrictions.
Kind regards
Christopher
Hi
Adolfo questions the more explicit prohibition of instance creation in the rephrasing of:
QVT 1.2 8.2.1.12 Helper:
However it is illegal to create or update object instances within a helper operation except for pre-defined types like sets, tuples, and for intermediate properties.
by
QVT 1.3 proposal:
A helper may modify but not create Class instances. A helper may modify mutable DataType values such as List or Dict.
A helper or query may create mutable DataType values such as List or Dict or immutable DataType values such as Tuple, Set or String
I think that the new words are clearer but equivalent.
The prohibition ensures that all object creation is internally visible to 'resolve' which considers only mappings and not helpers.
Anyone agree/disagree?
REgards
Ed Willink
_______________________________________________
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/10783 - Release Date: 10/08/15
