[language] Support contextual classes

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 550166 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 18, 2019 03:48 EDT | | Modified | Oct 09, 2019 05:44 EDT | | Blocks | 551954 | | See also | 506817 | | Reporter | Ed Willink |

Description

If a transformation requires non-trivial intermediates, perhaps as part if a small side transformation, it may be convenient to define the classes in the transformation.

QVTo supports contedxtual classes. Some of the QVT spec examples suggest this is supported even if the grammar doesn't.

As a consequence of introducing package hierarchy, it turns out that parsing already supports OCLinEcore classes and content below a package.

Parsing is even partially tested by /org.eclipse.qvtd.xtext.qvtrelation.tests/models/misc/Packages.qvtr serialization is 'conveniently' skipped.

---

For the most part the OCLinEcore syntax is reasonable.

But is the 'attribute'/'property' distinction helpful?

How do 'operation' and 'query' co-exist?

Is it too bloated?

[eclipse-qvtd-bot]

By Ed Willink on Aug 18, 2019 05:25

(In reply to Ed Willink from comment #0)

As a consequence of introducing package hierarchy, it turns out that parsing already supports OCLinEcore classes and content below a package.

Correction. QVTbase.xtext duplicates the OCLinEcore functionality, so we have freedom to adjust slightly.

[eclipse-qvtd-bot]

By Ed Willink on Aug 26, 2019 04:33

What is "this"?

The original no-"this" made the sources of contextual operations weird and contextial properties hard.

A full "this" would be a RelationalTransformation necessitating a new "this" domain/usage/TypedModel. This was tried together with reification of QVTr contextual properties as QVTi contextual properties. This all seemed a bit bloated, so...

A lightweight "this" can create a Transformation class as part of the trace metamodel, re-using the middle/trace domain/usage/TypedModel. Oops it is a different type, contextual properties must be copied to the trace. QVTi contextual properties are redundant. Oops contextual operations/queries are in the wrong "this". Must copy them across too. QVTr2QVTs must change from QVTr "this" to lightweight "this" to gether with all its features. QVTi queries look silly; they should be in the trace metamodel. Two "this" classes is uncomfortable ...

Reverting to a full/regular "this" which is almost mandatory since if "this" exists it should be possible to do "this.oclType()...." to reflect on the QVTr transformation; pretty impractical on a lightweight "this". The difficulties of a regular/full "this" are perhaps less than a lightweight/fudged "this".

(The trace of a transformation execution should identify the values of all relevant configuration values. This is easy as an instance of the lightweight "this" that is part of the trace metamodel. For a full "this", we either have to create a trace class for the transformation (a lightweight this with properties only) or ensure that all relevant properties are referenced by relation trace instances.)

---

At runtime there must be a full "this" with standard EObjectImpl functionality which is too rich to multiply inherit into AbstractTransformer so this will have to be delegated. Invocation of contextual queries may have to be differently non-standard.

[eclipse-qvtd-bot]

By Ed Willink on Aug 26, 2019 04:35

(In reply to Ed Willink from comment #2)

At runtime there must be a full "this" with standard EObjectImpl functionality which is too rich to multiply inherit into AbstractTransformer so this will have to be delegated. Invocation of contextual queries may have to be differently non-standard.

Many transformations may be no-"this" so we want to avoid imposing the cists of loading the Tx metamodel. The delegated "this" must be created lazily.

[eclipse-qvtd-bot]

By Ed Willink on Aug 26, 2019 05:17

(In reply to Ed Willink from comment #3)

The delegated "this" must be created lazily.

Mapping trace classes are not explicitly identified in QVTi. Rather the QVTi code uses the explicit trace types in set/... statements. Introduction of a 'contextType' declaration for the QVTi "this" seems inconsistent and unnecessary. The entry point mapping can have code to create the lazy instance as appropriate.

[eclipse-qvtd-bot]

By Ed Willink on Aug 27, 2019 03:10

(In reply to Ed Willink from comment #4)

The entry point mapping can have code to create the lazy instance as appropriate.

Lazy creation is a really simple guarded create and assign. Putting this in an entry point provides the redumdamt flexibility for multiple entry points to do different things.

QVTi type checking and CG is impaired if the trace type is not known.

1) Current fidge: use fitst "Tx" prefixed class name in a(the) used package of a(the) trace typedmodel 2) Ditto with an EAnnotation 3) Ditto with a "TransformatinExecution" super class 4) A "context" declaration in the QVTi Tx imports section 5) A name : instance-type in the QVTi Tx header

4) The Tx imports section lacks clear keywords so ther e can be name conflicts. 5) is probably best.

Does a QVT Transformation have a contextVariable. If so what is its type?

a) no contextVariable => waht is "this" resolved to by the parser\ b) RelationalTransformation-typed context variable => consistent for oclType() reflection but violates QVTb's ContextTypeIsTransformation WFR\ c) (Imperative)Transformation-typed context variable => inconsistent for oclType(), lacks contextual features\ d) intnaceType-typed conext vraible => inconsistent for oclType(), lacks contextual features, violates WFR.

?? b) retains correct type for "this" navigation. so demote the WFR to distinct QVTc/i/r variants. CG/execution must dstinguish between contextVariable type for parsing and Transformation instanceType for execution.

[eclipse-qvtd-bot]

By Ed Willink on Aug 28, 2019 16:51

Contextual classes (extra classes) has got confused with the context class for the run-time trace of the transformation. Most of the above comments belong on Bug 506817.