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

Because the context can only be a Class instance, I think my words are ok.

What is traced surprised me when I pinned it down. But to trace the non-parameters would require deep tracing of object construction helpers. It's just not practical. You could have a 'traceable' tool option that prohibited all use of object construction that was not observable through mapping tracing, and which prohibited untraceable object mutation and ....

My words are my best attempt to expose what is already suggested. In part they are a provocation to Christopher or Sergey to object to them. This all started with from Christopher's query about what does get traced. Christopher clearly doesn't object to them. Sergey hasn't commented.

Unless someone identifies a real problem causing me to withdraw the resolution, that's probably what will materialize.

    Regards

        Ed Willink

On 14/10/2015 21:51, Adolfo Sánchez-Barbudo Herrera wrote:

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}

I can´t argue if this is what it SHOULD be specified. I didn´t simply expect:
- updated (non-created) objects be returned by a resolve call, as it occurs in a), b) and c)
- as commented "source.resolve()->includes(source)" as it occurs in c)

However, after another QVT spec reading, you are right, updated objects should be considered:

"A resolve _expression_ is an _expression_ that inspects trace objects of the transformation in order to retrieve target objects created or updated by mapping operation invocations executed previously on source objects. Conceptually, for each mapping invocation, the transformation records the correspondence between source and target objects participating in a given mapping invocation."

So just a couple of additional thoughts:
- I don´t think it´s worthwhile to disinguishing between context-parameter and in-parameters, specially providing that context-parameters can also be inout. I´d write:
  • in-parameters - the in (and inout) parameter objects or values (including the contextual parameter).
- One concern comes to my mind: what happens with objects that are created/updated inside the transformation but are not part of the mapping parameters . Shouldn´t they be considerd by resolve expressions ?

Regards,
Adolfo.


_______________________________________________
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/10820 - Release Date: 10/14/15


Back to the top