[specification] Add domain-selection to allInstances()

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 445071 | | Status | NEW | | Importance | P3 normal | | Reported | Sep 25, 2014 07:06 EDT | | Modified | Jan 02, 2016 13:47 EDT | | Reporter | Ed Willink |

Description

allInstances() is domain-specific in QVT.

Certainly needs a different run-time operation.

Maybe needs a parser tweak to special case the non-standard functionality.

Else run-time operation must be able to access the transformation metamodel to determine the domain. (Requires a change in ClassifierAllInstancesOperation to use the dispatch API and to the code generator to exploit it.)

[eclipse-qvtd-bot]

By Ed Willink on Sep 25, 2014 10:19

Using allInstances() on an output domain seems pretty dubious.

Using allInstances() on a middle domain seems like careless programming.

So maybe OCL's allInstances() is always interpreted with respect to all input domains and optionally new operations support alternate functionalities. See Bug 445105.

OMG Issue raised.

All that is needed to resolve this bug is to follow the OMG issue suggestion and have QVTiModelManager discover all input domains from the MetaModelManager and implement QVTiModelManager.get(Type) accordingly.

[eclipse-qvtd-bot]

By Ed Willink on Sep 26, 2014 11:16

(In reply to Ed Willink from comment #1)

OMG Issue raised.

19621

[eclipse-qvtd-bot]

By Ed Willink on Jan 11, 2015 12:22

Successfully committed to master:

The AbstractTransformation maintain a 'set' of caches for each ClassId for which allInstances() is used. The 'set' is organised as an array index by a ClassIndex - a small statically allocated Integer. This works for input models and supports the allInstances currently generated by the QVTr...QVTi scheduler.

Unsuccessfully developed on ewillink/445071

It is relatively easy to augment the createXXX code to update allInstances as well as middle-opposite caches. This might appear to support the allInstances also generated by the QVTr...QVTi scheduler. But the OCL CG only supports local data dependencies via let-variables; there is no support for global variables and associated side effects, consequently common subexpression elimination has no inhibition on hoisting the allInstances calls too early.

There is no clear permission in the specification for QVT to support allInstances on middle/output models and the failure of CSE demonstrates that such allInstances is dependent on co-operative pragmatics between reader and writer.

There is no clear need for the scheduler to use allInstances for middle/output models so the only immediate need for such support is to accommodate inadequate scheduling.

So probably WONTFIX on middle/output allInstances. Let's fix the scheduler and avoid the quadratic or worse behaviour that is likely associated with using guarded allInstances rather than navigated instances.

[eclipse-qvtd-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 12, 2015 05:31

Hi Ed,

It make senses. What ever CSE logic was, under the premises of a free side-effect language, is understandable it doesn't work any more for a side-effects one such a transformation language.

However, I believe that it's not a matter of just improving the scheduler. I can't believe that one day, it won't come up an example in which you will want/need to use allInstances on outputs.

Other practical known languages such as ETL and ATL indeed support this.

Cheers,\ Adolfo.

[eclipse-qvtd-bot]

By Ed Willink on Jan 12, 2015 06:13

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #4)

It make senses. What ever CSE logic was, under the premises of a free side-effect language, is understandable it doesn't work any more for a side-effects one such a transformation language.

The current CG 'placement' algorithm for let-variables is flawed and too complicated. I'm expecting to be motivated to rewrite once a real problem occurs. This is not it. But a rewrite could understand SSA-style init-read dependencies.

However, I believe that it's not a matter of just improving the scheduler. I can't believe that one day, it won't come up an example in which you will want/need to use allInstances on outputs.

Perhaps, but its spelling will not be "allInstances".

[eclipse-qvtd-bot]

By Ed Willink on Apr 21, 2015 14:06

(In reply to Ed Willink from comment #5)

However, I believe that it's not a matter of just improving the scheduler. I can't believe that one day, it won't come up an example in which you will want/need to use allInstances on outputs.

Perhaps, but its spelling will not be "allInstances".

QVTo defines an extended Standard Library. QVTc/QVTr don't.

The QVTo library contains:

• generic functionality that could be promoted to the OCL Standard Library
• mutation functionality that is QVTo-specific
• model functionality that could be shared with QVTc/QVTr.

The most useful class is Model with query methods:

• objects
• objectsOfType
• rootObjects

objectsOfType is ambiguous, so for consistency with OCL there should be objectsOfKind and objectsOfType.

If we define the domain name as a name for a Model containing the domain elements, we can write for

transformation umlRdbms {\ uml imports SimpleUML;\ rdbms imports SimpleRDBMS;\ imports SimpleUMLtoRDBMS;\ }

uml.objectsOfKind(Class) or SimpleUML.objectsOfKind(Class)

[eclipse-qvtd-bot]

By Ed Willink on Jan 02, 2016 13:47

A QVTbase and QVTimperative specialization added long ago. It supports

Model::allObjects()\ Model::objectsOfKind(TT)(type : typeof(TT))\ Model::objectsOfType(TT)(type : typeof(TT))\ Model::rootObjects()

QVT 1.3 defines a declarative semantics for allInstances(). This needs implementing (one day) even if we never expect to use it.