eclipse-ocl-bot
commented
1 month ago By Ed Willink on Sep 14, 2017 09:51
Implementing the extra first PathElementCS solves the AliasName::AliasName problem. Now correctly resolved as alias::class.
But one test failure on testLoad_Bug450950_ocl for
import bug450950a : 'Bug450950A.oclinecore'::bug450950because the simple code triggers a cyclic reference. Simple fix, the first path element in an ImportCS cannot be an alias.
A further compatibility issue arises with Model imports causing a test failure in testQVTiCompiler_ClassesCS2AS_bug459225_CG. Easiest to correct the one bad manual import than to introduce compatibility that then gives OCL regresssion failures. (The editor consistently complains about the bad model import.)
Pushed to master for M2.
| --- | --- | | Bugzilla Link | 522221 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Sep 13, 2017 03:09 EDT | | Modified | Sep 14, 2017 09:51 EDT | | Reporter | Ed Willink |
Description
aliases are useful but since the alias is not a true model element its interaction with other model elements is unclear, making AS2CS synthesis fragile. A particular problem occurs for testQVTcCompiler_Forward2Reverse_CG where the DoublyLinkedList class name is also used as an alias. The AS2AS produces AliasName::AliasName fr which the first is resolved as a Class not an alias.,
Intent: an alias provides a short name for use in place of a long name, usually the first element of a qualified name::
alias::...
but, sometimes for packages in Complete OCL
package alias
An alias should never be used as an intermediate or final qualified name, property, iterator, operation, .... name
In QVT, an alias may also be used as a used package of a TypedModel.
Therefore the current support of import during normal lookup is misguided; it should be for the first of multiple PathElementCS in a PathNameCS or for Package references.
A successful lookup from PathNameCS occludes contributions from outer scopes.