Closed eclipse-qvtd-bot closed 17 hours ago
By Ed Willink on Jun 10, 2016 05:30
Contextual operations are equally applicable to QVTc/i/r so for shared functionality, we need to address the no-QVTbaseCS asymmetry allowing at least an AbstractTransformationCS to share currently duplicated code.
This code is also shared with OCLinEcore. Perhaps OCL needs to be:\ Base, EssentialOCL, OCLBase, OCLinEcore so that OCLBase can be re-used by OCL-like languages with structure.
By Ed Willink on Jun 13, 2016 07:12
Introducing a new "package" construct enables the clumsiness of a long package qualification on a transformation name and the difficulty of specifying URIs to be solved.
In OCLinEcore style, "package name : pfx = 'URI' { ... }" can be wrapped around nested package, class or transformation constructs. (For QVTc/i map constructs remain outside any {} scoping - inconsistent, but no-change.
Additionally the package name may be qualified Java-like, but only the innermost gets a nsPfx, nsURI. This allows
package org::eclipse::qvtd::xtext::qvtrelation::tests::hstm2fstm\ {\ transformation HierarchicalStateMachine2FlatStateMachine(hier:hierMM, flat:flatMM)\ { ...\ }\ }
as an alternative to
transformation org::eclipse::qvtd::xtext::qvtrelation::tests::hstm2fstm::HierarchicalStateMachine2FlatStateMachine(hier:hierMM, flat:flatMM)\ { ...\ }
By Ed Willink on Jun 13, 2016 08:02
Pushed to master for M1.
By Ed Willink on Nov 01, 2016 04:54
Qualifying transformation names did not address the original issue. See. Bug 506817.
| --- | --- | | Bugzilla Link | 495331 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Jun 02, 2016 13:06 EDT | | Modified | Nov 01, 2016 04:54 EDT | | See also | 506817 | | Reporter | Ed Willink |
Description
QVT can be extended by explicutly embedding things in the original metamodels or by importing Comoplete OCL. Both approaches are a bit naff.
Much better to allow definition within QVT (OCLinEcore syntax).