[qvts] Rationalize Navigable eges and opposites

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 534371 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | May 04, 2018 09:55 EDT | | Modified | Apr 28, 2019 03:39 EDT | | Blocks | 507096, 530054 | | Reporter | Ed Willink |

Description

The categorization of CastEdge+NavigationEdge as NavigableEdge seemed like a good idea, but it doesn't really work. A CastEdge has an irregular orphan pseudo-Property. Other edges are also bidirectionally navigable, e.g. a TuplePartEdge dismantles / constructs. Even some operations are invertible.

Perhaps all mapping edges are potentially navigable and correspondingly inverse navigable.

The merge analyses struggle with equivalent but different cast cascades. Perhaps these could be hidden behind a Navigation with target type, cost, algorithm , ...

?? Edges inherit Navigation to allow unwrapped use, while a CompoundNavigation wraps a multi-edge path ?? A separate CompoundNavigation for each source-target combination. ??

[eclipse-qvtd-bot]

By Ed Willink on May 16, 2018 10:38

Is CastEdge needed at all? If the every edge navigation/node initialization is checked for type conformance anyway, CastEdges can just be eliminated.

[eclipse-qvtd-bot]

By Ed Willink on May 18, 2018 03:37

A brutal elimination of cast edges causes only one challenge: how to translate oclAsType(). Using an 'equals' edge, everything passes except 11 of the OCL2QVTiTestCases. An 'equals' edge is intended to be predicate between two alternative evaluations; not the oclAsType() functionality.

The current support has a potential for optimization of redundant casts and inverse navigation. Neither are at all likely, and both are more appropriate to per-operation optimizations rather than inflicting a CastEdge and a NavigableEdge confusion throughout.

Change oclAsType() to a regular operation that one day might support inverse evaluation, like some other operations, and might have a multi-related-use optimizer.

[eclipse-qvtd-bot]

By Ed Willink on Apr 24, 2019 03:47

Bug 530054 motivates a new DataTypeEdge varuant of NavigableEdge from a DataType to its mapped singleton. This is arguably another -not-Property NavigableEdge.

(In reply to Ed Willink from comment #2)

A brutal elimination of cast edges causes only one challenge: how to translate oclAsType().

There are two types of CastEdge.

A matched bidirectional CastEdge guarantees that the target is conformant, consequently it can be eliminated by changing the source to the conformant type. oops, if e.f. in OMF QVT 1.3, a NamedElement is separately cast to a Class and a Package (because we might be using a Module/Transformation), the source type must be a multi-type of Class-and-Package. This is a very rare use case, so it would be nice if it can be entirely polymorphic hidden behind a MultiCompleteClass or MultiClassDatum.

A computed unidirectional CastEdge is just an expression. An oclAsType() operation should do fine in its stead. Unless of course we support a combined oclIsKindOf/oclIsType idiom. An oclAsKindOf() operation might return null for non-conforming types avoiding the need to split control and data flows.

[eclipse-qvtd-bot]

By Ed Willink on Apr 26, 2019 14:49

(In reply to Ed Willink from comment #3)

entirely polymorphic hidden behind a MultiCompleteClass or MultiClassDatum.

Chnaging ClassDatum.completeClass to ClassDatum.completeClasses is fairly simple.

Some code such as toString/conformsTo doubles up ok.

Some code such as isDataType/isCollectionType factors out some inelegant peeking

Some code such as getPrimaryClass(), particularly with a view to a construction cannot be multi-type. Throw an ISE for now.

The main algorithms are conformsTo, commonType and collection-element

Introducing a CollectionClassDatum makes getElementalClassDatum easy.

Localizing all conformsTo in QVTscheduleUtil for ClassDatum/completeClass only makes code clearer.

Pushed to master for M2.

[eclipse-qvtd-bot]

By Ed Willink on Apr 26, 2019 14:50

(In reply to Ed Willink from comment #1)

Is CastEdge needed at all?

Yes. During QVTs construction we do not know which casts are also used as oclIsKindOf inputs. We must therefore create CastEdges during creation and then optimize them away later.

[eclipse-qvtd-bot]

By Ed Willink on Apr 28, 2019 03:39

(In reply to Ed Willink from comment #5)

Yes. During QVTs construction we do not know which casts are also used as oclIsKindOf inputs. We must therefore create CastEdges during creation and then optimize them away later.

Done. All old uses of CastEdges changed to not isCast assertions to confirm that all CastEdges are rewritten. There are no compound navigations. There are no getCastTarget helpers.

Pushed to master for M2.

There is now no difference between NavigableEdge and NavigationEdge. Maybe about to chanhge for Singleton/DataType/SharedAggregate edge. Bug 530054.