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
Traceability, I've tried not to step in more into traceability issues, because you are already receiving feedback from Christopher which has more experience in real world scenarios. I'll have a look to the related resolutions again, and bring comments. Can you please point out the issues so I don't overlook anyone ?. 

Access vs extends. Transformation are classes. Just think of what Java does. If you import a class you can optionally instantiate them, if you want to extend you have to explicitly do it in the concrete syntax. In java, it's clearly access by default. Although in Java you can only extend one class (which makes the extend by default stupid), I don't see any convincing argument about why the specification should say the opposite for QVTo transformations. Although both bring interesting points of view, I sympathize with Christopher's arguments rather than Sergey's ones. 

[NB Apparently, I'm allowed to vote in JIRA for QVT 1.3 ballots. I shouldn't be....]

Regards,
Adolfo.

On Wed, Oct 14, 2015 at 10:55 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
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

Back to the top