Community
Participate
Working Groups
http://issues.omg.org/browse/QVT14-56 raised the possibility of checkonly PropertyTemplateItems to handle the case where it was not clear whether the RHS was re-using/creating. However this seems to be an implementation pragmatism. A naive execution of the RHS as a call tree may easily realize/assign duplicate output elements. e.g. where { doIt1{x,y}; doIt2{x,y}; } with doIt1 and doIt2 identical. Each realization/assignment must be sensitive to a prior execution and re-use the previous value if the same, or give a transformation failure if doIt1 and doIt2 are subtly different. This may be closely related to an incremental execution, except that a first incremental assignment my change, failing only on the second change. An analysis of the RHS as a call tree should enable most realizations/assignments to be categorized as conflict free avoiding the need for run-time testing. It may be helpful to diagnose the conflict hazards for the transformation author. It may even be possible to prohibit them.
(In reply to Ed Willink from comment #0) > Each realization/assignment must be sensitive to a prior execution and > re-use the previous value if the same, or give a transformation failure Most of this functionality is already there. An object slot is hazardous if it may be accessed too soon. It has an ASSIGNABLE/ASSIGNED SlotMode to track the first assignment. Double assignment is a failure. We just need to activate the hazardous functionality for multi-assignables and change the instant failure of a double assignment to a conditional failure on inconsistent re-assignment.
Bottom line: a relation defines a pattern that is true on completion. If multiple relations/executions realize a consistent non-aggregated output object many times that is not a problem, the many must be unified as one. ATL2QVTr provides two challenging relations. a) parent creations - mapModule a Module maps directly to a RelationalTransformation but also to Package/Model ancestors. There is at most one Model so may be a Key unifies, but parents can certainly be created. b) referenced create - mapSimpleInPatternElement a SimpleInPatternElement maps to an ObjectTemplateExp that references a TemplateVariable that must be created as a child of a Relation resolved by a when.
The PartialPhilosphers ;problem from Bug 515490 demonstrated two problems here. a) to sequence Eat after PickupLeft, the input hasLeft of Pickup was tested. Wrong should have been the output of Pickup, but without a checkonly guard that would have been a re-assignment not a test. Workaround: test the previous relation in a when or the variable in a guard. b) multiple assignment were not detected allowing a spuriously successful execution.
(In reply to Ed Willink from comment #3) > b) multiple assignment were not detected allowing a spuriously successful > execution. A multiple assignment can only be detected if there is a SlotState wwhich will currently nly happen if the state is observed by something. ?? Any slot assignable from more than one Mapping should be auto-observed. Multiple assignments within the same Mapping will usually be distinct since different objects reached from digfferent heads; but is this always true ??
(In reply to Ed Willink from comment #4) > A multiple assignment can only be detected if there is a SlotState wwhich > will currently nly happen if the state is observed by something. ?? Another design rule check for QVTiProductionConsumption ??
A quick experiment to improve the current "Re-assignment" error to a warning for a redunadnt re-assignment fails for the LazyObjectManager which has no knowledge of the pre-assigned value. (In reply to Ed Willink from comment #1) > We just need to activate the hazardous functionality for multi-assignables > and change the instant failure of a double assignment to a conditional > failure on inconsistent re-assignment. Richer multi-assignment API.
(In reply to Ed Willink from comment #0) > http://issues.omg.org/browse/QVT14-56 raised the possibility of checkonly > PropertyTemplateItems to handle the case where it was not clear whether the > RHS was re-using/creating. However this seems to be an implementation > pragmatism. As identified in the original issue, there is a workaround that ensures that an appropriate "when" predicates the checked parts of the output pattern. It is just inconvenient for the transformation author to structure/be aware of the structure of the invoked when. We can therefore ignore checkonly PropertyTemplateItem as a future syntax sugar for now.
