Re: [qvto-dev] QVT 1.3 Traceability proposal

[Christopher Gerking <christopher.gerking@xxxxxxxxxxxxxxxx>]

Hi

 

How helpful are classes such as TraceData or TraceRecord, if they are not in the scope of the resolve operations? I vote for a write-back, that is when the execution of transform() finishes, the accessed trace gets included by the accessing trace. In this way, the nested execution becomes subject to resolve operations.

 

 

Regards

Christopher

 

Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Montag, 12. Oktober 2015 19:09
An: qvto-dev@xxxxxxxxxxx
Betreff: Re: [qvto-dev] QVT 1.3 Traceability proposal

 

Hi

On 12/10/2015 15:39, Ed Willink wrote:

“This including any mappings executed by accessed or extended transformations or libraries”.

 

I basically agree. But what does this mean for resolving from within an accessed transformation? Is the trace data from the accessing transformation available? So is there an immediate write-through? That’s dangerous, because if one transformation accesses two other transformations (which share some mapping operations), the second transformation might fall over trace records created by the first one.

 

Alternatively, an accessed transformation could start with an empty trace data. At the end of the nested execution, there would be a write-back to the trace of the accessing transformation. I consider this as the most generally compatible solution.

 

Overall, the initial trace data should depend on whether the accessed transformation reuses the model extents from the accessing transformation. But I think this would imply too many hybrid forms and twilight areas for a clean specification.

 

Maybe I don't understand accessed transformations. I thought they were a variant of extended transformations with different name visibility rules. In both cases there is just one 'TransformationCallExp' and so only one trace data. I see no actual 'TransformationCallExp'to enable one transformation to invoke another.

I just found Transformation::transform()/parallelTransform()

Clearly a parallelTransform() cannot share its trace data. So IMHO, each distinct transformation invocation is 100% independent, requiring clear rules on sharing 'mutable' out extents passed as immutable in extents.

Bug. Status should provide access to the invoked transformation's trace data... TraceData, TraceRecord should be reified as visible classes (immutable by QVTo code). ? a new issue for QVT 1.4.

    Regards

        Ed Willink