eclipse-qvtd-bot
commented
1 week ago By Ed Willink on Sep 15, 2017 04:19
The QVTs Operation analysis identifies all the types/properties upon which the Operation transitively depends thereby ensuring that these are either assigned first to ensure a safe first evaluation. This is no help for re-evaluation where the change must be assessed.
The QVTs Operation analysis also identifies the access paths which in some cases could allow the caller to take responsibility for change handling. However in the general case the access path will revert to an all-something for safety.
There is no avoiding an Operation evaluation tracing its NavigationCallExps. Invocation of a helper function such as EcoreUtil.getRootContainer() can only be tolerated if an OCL equivalent is available for analysis, in which case it is easier to synthesize an instrumented version than to wrap a change detector around it.
| --- | --- | | Bugzilla Link | 522345 | | Status | NEW | | Importance | P3 normal | | Reported | Sep 15, 2017 03:20 EDT | | Modified | Sep 15, 2017 04:19 EDT | | Blocks | 522340 | | Reporter | Ed Willink |
Description
Given that everything that affects incremental re-evaluation must be traced, whatever affects a cached operation result must be traced. An operation therefore needs rather similar treatment to a mapping. The operation trace may of course need sub-traces, See Bug 522344.
We can distinguish traced and untraced operations, where an untraced is an operarion that has no external accesses; i.e. no NavigationCallExps other than perhaps Tuple properties. The trace of a traced operation must have aa sub-trace for the operation. The trace of an untraced operation can just cache the result.