[pivot] Use consistent self-specialization

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 582115 | | Status | NEW | | Importance | P3 normal | | Reported | Jun 25, 2023 00:03 EDT | | Modified | Aug 15, 2023 13:24 EDT | | See also | 581860, 580791, 582158 | | Reporter | Ed Willink |

Description

A TypedElement.type is a reference to an exact (specialized) type, which is a bit confusing for the case of a specialization of the unspecialized type and so much of the code uses the unspecialized type leading to different confusions from the inconsistency.

As so often, easier to think in Java. For

class My {\ void f(My my, My myString, My myT) {}\ }

my is wrong.\ myString is a consistent String specialization of My.\ myT is a self-specialization of My.

The self-specialization seems like weird bloat at the XMI level since actual and formal have the same value, but using the unspecialized type is inconsistent.

[eclipse-ocl-bot]

By Ed Willink on Jun 28, 2023 04:46

The StandardLibrary template creation has an isUnspecialized() guard that seems to be there solely to get the wrong answer.

contextType should of course be a My self-specialization not a My declaration.

[eclipse-ocl-bot]

By Ed Willink on Jun 28, 2023 04:59

Most code convets once a few resolveSelfSpecialization calls are added but testValidate_Bug543173_ecore highlights two issues:

package bug543173 : bug543173 = 'http://Bug543173'\ {\ abstract class ModelElement\ {\ attribute reference : Boolean[1] = 'false' { derived readonly transient volatile }\ {\ initial: \ Mapping.allInstances()->select(m : Mapping | m.to = self)->notEmpty();\ }\ }\ abstract class Link(T extends ModelElement)\ {\ property to : T[1];\ }\ class Mapping(T extends ModelElement) extends Link(T);\ }

The iterator should clearly be "m : Mapping(?)" even if we allow a syntax sugar omission of the "(?)".

The return from allInstances should be "Set(Mapping(?))" not the self-specialization "Set(Mapping(Mapping.T))"

Within a declaration, a self-specialization may be sensible. Outside it must be a wildcard-specialization. Need to resolve in conjunction with Bug 581860.

[eclipse-ocl-bot]

By Ed Willink on Jun 28, 2023 05:57

(In reply to Ed Willink from comment #2)

Need to resolve in conjunction with Bug 581860.

So if a WildcardType simplifies to a hidden TemplateParameter ... who owns it?

The iterator should clearly be "m : Mapping(?)".

The referred type cannot own a widcard on behalf of the reference.

Every type reference could have optional owned wildcards - e.g the IteratorExp

Or the ancestral ExpressionInOCL could have optional owned wildcards

Or the ancestral ExpressionInOCL's container ... e.g. the "reference" Property

Or the ancestral Classifier ... e.g the "ModelElement" Class

Or the Orphanage

The return from allInstances should be "Set(Mapping(?))" not the self-specialization "Set(Mapping(Mapping.T))"

But allInstances is declared as:

operation allInstances() : Set(OclSelf[*|1]);

so the need for a wildcard depends on whether OclSelf is templated. Ugh!

Putting a Wildcard variant of TemplateParameter in the Orphanage seems right; no AS change.

[eclipse-ocl-bot]

By Ed Willink on Aug 06, 2023 03:29

(In reply to Ed Willink from comment #2)

Within a declaration, a self-specialization may be sensible.

No it is dangerously cute. Consider

class MyMap<K1,V1> { operation<K2,V2>(Map m) ...}

is Map in Map m: Map(K1,V1) or Map(K2,V2) or Map(Map.K,Map.V) or ... any default would be 'right' sometimes, 'wrong' often and confusing always. The only safe inference is Map(?,?) to introduce new types/wildcards. If there is a constrint to an existing template paramter it should be specified explicitly.

Clearly there is no self-sepcialization.

[eclipse-ocl-bot]

By Ed Willink on Aug 06, 2023 09:02

(In reply to Ed Willink from comment #4)

Clearly there is no self-specialization.

for an explicitly signature. However the implicit type of self in e.g.

class Map<K,V> {\ property p : ..\ operation op : ...\ }

is equivalent to an explicitly typed:

self : Map(K,V);

[eclipse-ocl-bot]

By Ed Willink on Aug 15, 2023 13:24

We need three StandardLibrary resolutions

@NonNull Type resolveContextSpecialization(@NonNull Type asType);\ @NonNull Type resolveIncompleteSpecialization(@NonNull Type asType);\ @NonNull Type resolveLowerBoundSpecialization(@NonNull Type asType);

Using resolveIncompleteSpecialization for

Mapping.allInstances()->select(m : Mapping | m.to = self)->notEmpty();

gets a conformance validation error since we don't search for wildcard resolutiions.

For now using resolveLowerBoundSpecialization and all tests pass.

i.e. we do

... m : Mapping(ModelElement) ...

rather than

... m : Mapping(? extends ModelElement) ...