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

 

How should the debugging work? I mean, for an incomplete trace record, ‘resolve’ will always return null because there is no result. Thus, the behavior can’t be distinguished from the situation where the mapping hasn’t been executed and there is no trace record at all.

 

The bigger problem is that storing an incomplete trace record in case of an assertion failure could prevent a successful re-execution of a mapping. If we store the trace record at the beginning of init, then it must be clearly specified that a re-execution is only prevented if the trace record includes a result object. In contrast, if there is only an incomplete trace record without a result, then a full re-execution must still be possible.

 

Eclipse QVTo does in fact prohibit re-assignments to the result variable after the init section. The init section is the only place where the result can be initialized/set. Afterwards it is stored in the trace, before the population section starts. No re-assignment after init. I think this should apply to out parameters as well. Therefore I consider the a := … assignment in your example below as invalid.

 

mapping m(out a : String)...
  init{
   result := ...
 }
...
 end {
    a := result.name;
 }
}

 

Regards

Christopher

 

Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Mittwoch, 14.
Oktober 2015 17:40
An: qvto-dev@xxxxxxxxxxx
Betreff: Re: [qvto-dev] Oustanding discussion for QVT 1.3 Ballot 3

 

Hi Christopher

Replying to you first since you are an hour ahead. But please keep an eye out for my imminent reply to Adolfo; there are some important clarifications.

An early trace record serves two purposes.

a) it is available to inhibit re-execution within the init section.
b) it is available to inhibit / trace / debug following an assertion failure

But this is exactly as you write, it exists for a failure in the init, so surely it is created at the start of init? You confuse me.

From my limited knowledge this must happen before "result := "

When you write that "in Eclipse QVTo, a mapping can't re-assign", I am confused. As an OMG specification author I am not that concerned about bugs in a particular implementation. If however you mean that QVTo provides no syntax to permit such a re-assignment, then that is relevant.

The scanario I am considering is:

mapping m(out a : String)...
  init{
   result := ...
 }
...
 end {
    a := result.name;
 }
}

a must be traced on exit.

    Regards

        Ed Willink

On 14/10/2015 16:05, Christopher Gerking wrote:

Hi

 

Trace record at the start of init: How helpful are they? Without the results, a trace record doesn’t yield much. If there is an assertion failure inside the init section, the incomplete trace record already exists (without the result). Since there is a trace record, the mapping won’t re-execute for the same input. Resolve will return null. Are these effects desired?

 

Trace record results initialization: in Eclipse QVTo, a mapping can’t re-assign the result after the init section, only mutate it. Therefore the result can be stored in the trace right after its instantiation. It might still change, but not re-assigned. So why waiting until after the end section?

 

 

Regards

Christopher

 

 

 

Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Mittwoch, 14.
Oktober 2015 11:56
An: QVTOML developer mailing list
<qvto-dev@xxxxxxxxxxx>
Betreff: [qvto-dev] Oustanding discussion for QVT 1.3 Ballot 3

 

Hi

I am awaiting comments (today) if the following clarifications/changes are to be revised:

The trace record is created at the start of the init section.

The trace record result fields are initialized at the end of the termination section.

All late resolution property writes occur after all affected properties have been read.

I've added two strong sentences to Trace Record.

A _trace record_ is created by every mapping execution. If execution fails the _out\-parameters_ and _result\-parameters_ are _null_.

A _trace record_ is created or re-used by every mapping invocation. If no mapping is executed, the _executed\-mapping_, _out\-parameters_ and _result\-parameters_ are _null_.

---

Default for access/extends is still undecided.

As an Eclipse QVTo committer, I lean towards no breakage and so extends
As OMG QVT chair, I lean towards common sense and so access

If SmartQVT is/was extends as default then my dilemma goes away.

---

The following discussions are deferred:

Nested transformation trace data remains unspecified. http://solitaire.omg.org/browse/QVT13-124 raised. Suggestion is that it is accessble via Status and additional optional first resolve() Status argument.

     Regards

        Ed Willink




_______________________________________________
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