QVTd In-place and Copy Transformations

The QVT specification has vague indications that QVTr / QVTc supports in-place transformations but provides no real details.

Copy transformations in which the output is very similar to the input are not considered at all.

This working document considers how copy and in-place might be supported. It takes over from

• https://bugs.eclipse.org/bugs/show_bug.cgi?id=462165
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=512028
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=512735

The Use Case

Support an EcoreUtil.Copier-like capability:

• deep copy of an input model
• arbitrary input classes, some of which may use an extension metamodel not known until run-time
• references to copied class instances are redirected to the copies
• references to external class instances reference the unchanged external class instance

QVTr solution

Impossible, since there is no ability to create a dynamically determined type.

Even if all classes are known at programming time, it is necessary to enumerate an explicit copy of each class. See the

-- copy an ocl expression
-- For space reasons this relation is not expanded out here

at the end of the RelToCore example.

QVTc solution

Impossible, since there is no ability to create a dynamically determined type.

Copy versus In-Place transformation

These could be treated as separate challenges, but from a programmer perspective they are identical; a potentially late run-time option can specify whether the output overlays or replicates the input. We therefore treat copy and in-place as the same problem when considering UMLX, QVTr, QVTc. THe distinction may perhaps occurs as alternate qvts2qvti synthesizes generate different code, or perhaps just in the qvti run-time.

Copy versus non-copy transformation

A non-copy transformation specifies all created types explicitly. Output slots are populated explicitly.

A copy transformation can re-use the source type/object as the target type/object. Output slots may be populated implicitly (by copy/re-use).

Using a non-copy language semantics for a copy requires all slots to be enumerated to participate in the copy. This is verbose and error prone.

An alternative copy language semantics need only specify deviations from a perfect deep copy. cf. Henshin's create/delete markups.