Re: [qvto-dev] Oustanding discussion for QVT 1.3 Ballot 3

[Adolfo Sánchez-Barbudo Herrera <adolfosbh@xxxxxxxxx>]

Hi Ed,

A couple of additional comments below:

meters are traced twice.

Class instances are traced by reference and so are blind to mutation. Specification-wise a pair of references is not a problem. If Eclipse QVTo copies instance content, then that is an issue for Eclipse QVTo. To fully support incremental execution traced Class Instances would need to be treated as DataType values so that everything is deepcloned, but of course taking care to share referenced objects in their correct states.

Since the Class instance reference is a reference, it cannot be chnaged to another object so the double trace is redundant.

DataType values (including Dict) are traced by value, so the entire inout Dict is deepcloned twice. Not a problem specification-wise. An implementation might save memory on one of the deepclones. My original QVT Traceability paper thoughts dismissed inout Dict tracing as too expensive in parctice and suggested that inout parameters be excluded from tracing. However redundant execution/re-use requires them to be in the trace. Eclipse Qvto appears to deepclone. I have twice asked Christopher if he is happy with this clear specification and he has not objected. Sergey seems to be busy/elsewhere.

DataType values are passed by reference-to-variable so the entire value may be changed, and so a double trace is necessary.

I was originally worried about the following situation:

source.resolve()->includes(source)

But in principle source should be a context-parameter rather an in-parameter (regardless the mapping has inout parameters or not) so my original concern seems a red herring.

The next suspicion: inout-parameter

If a Class instance acts as a inout parameter in a mapping execution, and the mapping simply modifies a property of that class, it would happen that an object which has been updated rather than created would appear as a result of a resolve operation call.

To try to get an agreement. Can you please answer to the following questions ?

Shouldn´t a resolve operation return the objects created during a mapping execution ? I think both agree on this: Yes.

Shouldn´t a resolve operation return the objects "updated" during a mapping execution ? I´d say NO, but your OCL-based definition invites me to interpret YES.

If it is YES, shouldn´t the context-parameter for the case of inout mappings also be considered as the result of a resolve _expression_ ?

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

No. This is an ambiguity that my words and pseudo-code clear up. Given:

Tuple{gOut, hOut} t := aIn.map m(bIn, cIn, dInout, eOut, fOut)

{aIn,bIn,cIn,dInOut} are traced to {dInout,eOut,fOut,gOut,hOut}

so all sources for the dInout target/ m mapping are {aIn,bIn,cIn,dInOut}.

[I still believe, that the invresolve expressions are wrong since you are filtering with types from the Target metamodel rather than the Source one]

I see... Unfortunately I don´t have the types of the excercise all the variantes, but your example is very helpful to also clarify the other discussion (the previous one above). 

So providing that the logic of mapping m does something with the following inout/out parameters:

- dInout is simply modified (it changes an attribute)

- eOut comprises a Class instance newly created during mapping execution.

- fOut comprises a Class instance already existent prior mapping invokation (e.g. an object referenced by dInout)

Can you please state the result for the following resolve expressions ?

a) aIn.resolve(m) = ????

b) bin.resolve(m) = ?????

c) dInout.resolve(m) = ?????

d) gout.invresolve(m) = ????

d) eout.invresolve(m) = ????

d) fout.invresolve(m) = ????

e) dInout.invresolve(m) = ????

[NB perhaps an example like this should be included in the resolution]