| Re: [qvto-dev] Oustanding discussion for QVT 1.3 Ballot 3 |
On 14/10/2015 12:40, Ed Willink wrote:Hi Ed After reading the "final" issue resolution, I add the following comments here: QVTo-dev is a more open/accessible list. So I'll add my comments here about "http://solitaire.omg.org/browse/QVT13-102" and add a link back in JIRA. Since we don't have lines, I'll refer to "text" which you should be able to identify with a Ctrl+F facility in the issue resolution. Here we go: -------------------- Firstly you mention "... In the case of a standard mode execution for which no candidate mapping is selected, the trace record contains null entries for executed-mapping, out-parameters and result-parameters fields." Later one: "...If no mapping is executed, the executed-mapping, out-parameters and result-parameters are null." It sounded kinda redundant to me. Feel free to decide if you keep both or not. ------------------- An equivalent OCL-like query for SOURCE.resolve(T : TYPE | CONDITION) is I'm unsure (apologies for vagueness) if for inout parameters you are allowed to return a different object/value, but I'm concerned about what happens if the inout-parameter is the same object at the end of the mapping execution as the object which came in (regardless it is modified by the mapping or not), that might provoke that calls to source.resolve might return the same source object, which at least sounds awkward. I'm not sure what should be done, but I throw the discussion about if: selectedRecords->collect(out-parameters->union(result-parameters))... Should be selectedRecords->collect(out-parameters)->union(selectedRecords->collect(result-parameters))->excludingAll(selectedRecords->collect(in-parameters))... or at least selectedRecords->collect(out-parameters)->union(selectedRecords->collect(result-parameters))->excluding(SOURCE)... Probably the former, in a short form: selectedRecords.out-parameters->union(selectedRecords.result-parameters)->excludingAll(selectedRecords.in-parameters)... [NB Is there no excludingAll (i.e. subtract or set complements operation) in OCL library?. excludingAll works in Pivot- Eclipse OCL] In the same OCL _expression_. ->collect flattens the result, so ->flatten() seems unnecessary ] ----------------------- invresolve at 8.1.x.4 Whereas from one source object we might produce different output objects through different mappings, from one target there should be just one source object. In any case, filtering types/conditions should apply to source domain. Suggestion replace target.invresolve(t : Table | t.name.startsWith('_'))
target.invresolveIn(Class2Table, t : Table | t.name.startsWith('_'))
by
invresolve(Class)
invresolveIn(Class2Table, c : Class | c.name.startsWith('_'))
target.invresolve() // No filtering conditions: just one object can be the source of a created object
[NB 8.1.x.5 has similar issues with the same invresolveone expressions] ----------------------------- "deep value equality". Is this a standarized/well-known concept ?. I think I know that you refer, but... others might not. ----------------- In 8.1.x.7. Redundant execution In second paragraph, you comment what happens when input objects are modified, with respect to decide if a mapping is not re-executed (and returns previous outputs) In last paragraph, perhaps evident, but I think a sentence might be similarly added with respect to the out-put objects which also might be modified between redundant mapping calls. "...matching name and argument count." => "...matching name and arguments." ----------------- Removal of Mapping disjuncts as a reuse facility. To me disjunct is arguably a reuse facility, but I like the direction you want to give to that part. Perhaps using "mapping extension" rather than "re-use facility" is more appropriate. Another issue I find in that part is that you: 1. firstly mention mapping inheritance/merge as the only two reuse facility, 2. then clarify a disjuncting mapping. 3. then you mention: The execution semantics subsection below provides the details of these reuse facilities. Therefore I'd rework that part as follows: In section 8.2.15 Replace There are three reuse and composition facilities associated to mapping operations: 1. A mapping operation may inherit from another mapping operation. This means invoking the initialization section of the inherited operation after executing its own initialization section. 2. A mapping operation may also merge other mapping operations. This means invoking the merged operations after the termination section. 3. A mapping operation may be defined as a disjunction of other mapping operations. This means selecting, among the set of disjuncted mappings, the first that satisfies the when clause and then invoking it. The execution semantics subsection below provides the details of these reuse facilities By A mapping operation may be defined as an explicit disjunction of candidate mapping operations. This means selecting and executing the first candidate mapping whose when clause and other predicates are satisfied. The empty body of the disjuncting mapping is not executed. An implicit disjunction of candidate mappings is formed by overloaded mappings with matching name and argument count. Additionally, there are two
extension mechanisms associated to mapping operations: The execution semantics subsection below provides the details of these mapping extension mechanisms. ---------------- Final corrections: "In strict mode failure to evaluate..." => "In strict mode, failure to evaluate..." "This is shorthand for invoking it in the body of a ForExp _expression_" => "This is shorthand for invoking it in the body of a xcollect ImperativeIterateExp _expression_." ------------------- Regards, Adolfo. |