search

eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

[as2cs] nameless imports acquire name during roundtrip #1874

Open eclipse-ocl-bot opened 1 week ago

eclipse-ocl-bot commented 1 week ago

| --- | --- | | Bugzilla Link | 521100 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 18, 2017 03:43 EDT | | Modified | Aug 18, 2017 05:29 EDT | | See also | 521094 | | Reporter | Ed Willink |

Description

Bug 521094 provokes a test that demonstrates that an OCLinEcore

import 'http://www.eclipse.org/emf/2002/Ecore';

round trips to:

import ecore : 'http://www.eclipse.org/emf/2002/Ecore';

The problem is that the AS2CS goes to some trouble to synthesize an alias and probably avoid many name clash conflicts. These conflicts should be soluble by more explicit qualification.

Need to distinguish between accdentally and deliberately unnamed imports in the AS.

In the CS the name parses/serializes as null.\ In the Ecore EAnnotation we have missing/present.

In the AS we could add an isExplicit, but probably null/"" will do.

ES2AS converts missing to "" to inhibit CS alias synthesis.\ Lazy AS can be null to enable CS alias synthesis.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Aug 18, 2017 04:08

This is more fundamental. Why do we need an AliasAdapter to synthesize the names of import aliases? The original reason has probably been obsoleted by the introduction of Ecore Import EAnnotations to persist the original imports, so we do not need to reconstruct them.

Try eliminating the AliasAdapter.

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Aug 18, 2017 04:31

(In reply to Ed Willink from comment #1)

Try eliminating the AliasAdapter.

(AliasAnalysis actually.)

Test failures occur for traditional *.ecore that have no import EAnnotation. Need to move the alias synthesis to the AS Import synthesis rather than the AS2CS of ImportCS.

The AliasAnalysis also provides a useful pretty-printing cache to avoid hideously long fully qualified names. Now that we have AS Imports a possibly stale cache is probably more trouble than it is worth.

QVTd has derived AliasAnalysis classes that seem to be just bloat.

test and WIP pushed to ewillink/521100

eclipse-ocl-bot commented 1 week ago

By Ed Willink on Aug 18, 2017 05:29

A closely related problem that a rethink should solve.

If there are two nameless imports, one serialized to Ecore they collide on the null EAnnotation key losing the first. Multiple same-sourced EAnnotations could hide this but multiple same-source http://www.eclipse.org/OCL/Import EAnnotations could lead to different fragilities.

?? a reserved 'is-implicit' prefix to a synthesized alias name

?? use the nsURI as both key and value when implicit

?? use the nsURI as just key with null value when implicit

The final approach avoids bloat and complexity, although it is not forwards compatible. Forwards compatibility can be achieved by only migrating the value to the key when more than one null/blank name is required.

This latter fix can be incorporated with the Bug 521094 fix.

The revamp of AliasAnalysis remains to do.