Hi
Trace
record at the start of init: How helpful are they? Without
the results, a trace record doesn’t yield much. If there is
an assertion failure inside the init section, the incomplete
trace record already exists (without the result). Since
there is a trace record, the mapping won’t re-execute for
the same input. Resolve will return null. Are these effects
desired?
Trace
record results initialization: in Eclipse QVTo, a mapping
can’t re-assign the result after the init section, only
mutate it. Therefore the result can be stored in the trace
right after its instantiation. It might still change, but
not re-assigned. So why waiting until after the end section?
Regards
Christopher
Hi
I am awaiting comments (today) if the following
clarifications/changes are to be revised:
The trace record is created at the start of the init section.
The trace record result fields are initialized at the end of
the termination section.
All late resolution property writes occur after all affected
properties have been read.
I've added two strong sentences to Trace Record.
A _trace record_ is created by every mapping execution. If
execution fails the _out\-parameters_ and
_result\-parameters_ are _null_.
A _trace record_ is created or re-used by every mapping
invocation. If no mapping is executed, the
_executed\-mapping_, _out\-parameters_ and
_result\-parameters_ are _null_.
---
Default for access/extends is still undecided.
As an Eclipse QVTo committer, I lean towards no breakage and
so extends
As OMG QVT chair, I lean towards common sense and so access
If SmartQVT is/was extends as default then my dilemma goes
away.
---
The following discussions are deferred:
Nested transformation trace data remains unspecified.
http://solitaire.omg.org/browse/QVT13-124 raised.
Suggestion is that it is accessble via Status and additional
optional first resolve() Status argument.
Regards
Ed Willink