Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] Oustanding discussion for QVT 1.3 Ballot 3
Hi

On 14/10/2015 19:16, Adolfo Sánchez-Barbudo Herrera wrote:
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.

Results are the instances/values on exit. What's the problem?

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_ ?

Yes, so it could be traced again on output, but since it is necessarily a Class Instance it will be the same as the source reference. (Unless an heroic implementation clones instances, but that's its prpblem.)



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]

Ah!. Yes invresolve should be Class not Table; even though it is an implied metamodel.

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) = ????
{dInout,eOut,fOut,gOut,hOut}
b) bin.resolve(m) = ?????
{dInout,eOut,fOut,gOut,hOut}
c) dInout.resolve(m) = ?????
{dInout,eOut,fOut,gOut,hOut}
d) gout.invresolve(m) = ????
{aIn,bIn,cIn,dInOut}
d) eout.invresolve(m) = ????
{aIn,bIn,cIn,dInOut}
d) fout.invresolve(m) = ????
{aIn,bIn,cIn,dInOut}
e) dInout.invresolve(m) = ????
{aIn,bIn,cIn,dInOut}

[NB perhaps an example like this should be included in the resolution]
It's all in the OCL-like equivalent. Needs a real rather than artificial example, but that takes time.

NB. This is what I have specified. I would be pleasantly surprised if that's exactly what Eclipse QVTo does, but hopefully it's not a breaking evolution. I've shone a light into a number of dark corners.


_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.6140 / Virus Database: 4447/10818 - Release Date: 10/14/15


Back to the top