Open eclipse-qvt-oml-bot opened 6 days ago
eclipse-qvt-oml-bot
commented
6 days ago By Christopher Gerking on Oct 21, 2024 07:33
(In reply to Christopher Gerking from comment #0)
the
rule from the QVT standard, defined as ('::' )*
I wonder how these scoped identifiers should be resolved at all, at least with regard to the QVT specification. It defines a transformation header as follows:
eclipse-qvt-oml-bot
commented
6 days ago By Christopher Gerking on Oct 21, 2024 07:34
(In reply to Christopher Gerking from comment #1)
Should they inherit the namespace of the modules in which they are contained?
Not modules, of course it is units.
eclipse-qvt-oml-bot
commented
6 days ago By Ed Willink on Oct 21, 2024 15:28
(In reply to Christopher Gerking from comment #1)
I wonder how these scoped identifiers should be resolved at all, at least with regard to the QVT specification. It defines a transformation header as follows:
It is a bug in the language. The designers lacked a larger perspective and so a root transformation name was considered adequate. For QVTr/QVTc I have generalized to allow a transformation to be qualified. Just imagine using Java in the large without nested packages!
e.g. the QVTc
import DoublyLinkedList : 'DoublyLinkedList.ecore#/';\ import List2List : 'List2List.ecore#/';
transformation org::eclipse::qvtd::xtext::qvtcore::tests::forward2reverse::Forward2Reverse\ { ...\ }
NB A QVTo Transformation is primarily a Class albeit confusingly also a Package and a Package can be almost arbitrarily nested. The AS therefore supports nested packages. It is just he CS that is broken. For QVTc/QVTr I clarified a Transformation as just a class so package qualification is very desirable. For compatibility, just like Java, there is a default package.
I'm not sure what you mean by modules; my understanding has got confused by failing to learn what Java does. For UML etc, it is good practice to have a single Module at the root of a model with Packages below. (Sadly EMF conflates the 'EModule' with the Resource which is not an EObject.)
eclipse-qvt-oml-bot
commented
6 days ago By Ed Willink on Oct 21, 2024 15:39
(In reply to Ed Willink from comment #3)
I'm not sure what you mean by modules; my understanding has got confused by failing to learn what Java does. For UML etc, it is good practice to have a single Module at the root of a model with Packages below.
oops. I'm well confused. Obviously it is good practice to have a single Model at the root.
| --- | --- | | Bugzilla Link | 583602 | | Status | NEW | | Importance | P3 normal | | Reported | Oct 21, 2024 05:13 EDT | | Modified | Oct 21, 2024 15:39 EDT | | Reporter | Christopher Gerking |
Description
Eclipse QVTo allows to qualify mapping calls with a module identifier. For example:
myEClass.map MyExtendedModule::myMapping();
The effect of such a qualified call is that the isVirtual attribute is set to false. In particular, this allows a mapping to call its own super implementation that resides in a different, extended module (see https://issues.omg.org/issues/spec/QVT/fixed#issue-38194).
However it should be noted that Eclipse QVTo does not support fully-qualified identifiers. That is, the rule from the QVT standard, defined as ('::' )*, is only supported up to 2 simple identifiers – one for the owning module name, one for the mapping name. This is problematic for same-named modules differing in their fully-qualified names only.
Experiments show that adjusting the support is tricky, as it seems to require reworking the QVTo parser. The above limitation to 2 identifiers is due to the following parser rule:
featureMappingCallExpCS ::= map simpleNameCS :: simpleNameCS ( argumentsCSopt )
There is also an alternative rule with support for path names, but it does not seem to be invoked:
mappingCallExpCS ::= map pathNameCS ( argumentsCSopt )
The difference between featureMappingCallExpCS and mappingCallExpCS is not clear to me.