eclipse-ocl-bot
commented
1 month ago By Ed Willink on Jun 22, 2018 03:43
(In reply to Ed Willink from comment #0)
The bug goes away if there is an assignmentStarted flag to distinguish the assignments from the LUSSIDs construction.
Pushed to master.
Surely packages/types/properties should be handled eagerly with operations queued for a later treatment?
Yes bug remains open.\
The "normalizeTemplateParameters" parameter desperately needs an explanatory comment.
Yes bug remains open.
Given that there is a mandatory isExternallyReferenceable override to select what xmi:ids to allocate, a getChildren and a getReferences method could make the generic tree descent and generic crossreferences much less costly.
An experiment at moving the isExternallyReferenceable if-type logic to a visitor hits the problem that a derived extending Visitor for QVTd needs a lot of manual plumbing. Perhaps the AbstractExtendingDelegatingVisitor is needed after all.
Perhaps the CGTypedElementModelSpec technology should be applied to the Pivot, but a cleaner approach would be a lussids.ocl mix-in. The bigger challenge is to have a clean stable Pivot AS API with all the added functionality only in internal APIs. Is it possible for a Pivot model evolution to not require API filters?
| --- | --- | | Bugzilla Link | 536125 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 21, 2018 04:57 EDT | | Modified | Jun 22, 2018 03:43 EDT | | See also | 535842 | | Reporter | Ed Willink |
Description
Bug 535842 comment #2 identifies two stdlib test failures once an attempt is made to avoid calling assignLUSSIDs for the Orphanage.
The problem arises during a CS save where Xtext triggers an individual xmi:id assignment for a custom library troggering a comprehensive LUSSID assignment for the custom library but no actual assignment for the OCLmetamodel that is nonetheless marked as assigned. This confusingly results in unresolved proxies in a subsequent test.
The bug goes away if there is an assignmentStarted flag to distinguish the assignments from the LUSSIDs construction.
LUSSIDs.assignLUSSIDs has a plausible tree descent assigning LUSSIDs to externally referenceable elements. And for each element there is practive call fir everything gthat it references. The main purpose of this seems to be to ensure that an import assigns LUSSIDs to all possible importedc elements before they are referenced without any built-in knowledge in LUSSIDs as to what an import node is. This seems a rather costly sledgehammer and not an inherently sound one.
We have the usual problem that packages/types/properties can have identities locally resolved using a hierarchical algorithm. However operations require their parameter types to be resolved, potentially leading to a type-operation-parameter-type-operation-parameter-type cycle across two metamodels if everything is assigned in one pass. Surely packages/types/properties should be handled eagerly with operations queued for a later treatment?
The "normalizeTemplateParameters" parameter desperately needs an explanatory comment.
Given that there is a mandatory isExternallyReferenceable override to select what xmi:ids to allocate, a getChildren and a getReferences method could make the generic tree descent and generic crossreferences much less costly.