[pivot] TemplateParameter is not a Type, introduce TemplateParameterType

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 580511 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 04, 2022 03:45 EDT | | Modified | Aug 24, 2022 04:57 EDT | | Blocks | 509309 | | See also | 580363, 580407 | | Reporter | Ed Willink |

Description

Operation declarations have Parameters, and the implementation in the form of an ExpressionInOCL has corresponding ParameterVariables.

Similarly TemplateableElement declarations have a signature with TemplateParameters, but their implementation has bindings that also have TemplateParameter giving the awkward requirement that TemplateParameter is a Type.

Work on Bug 580363 to ensure that localizeSpecializations can use TypeIds consistently highlights that we have

The generalization: Collection()\ The partial specialization: Collection<>(Bag.T)\ The full specialization: Collection<>(String)

This requires TemplateParameter to be a Type, yet for a specialization, provided we don't lose the declaration point for which there is a hierarhical linear list of template parameters; e.g. C

::D::e<R,S>(....) allowing access to {P,Q,R,S} as template parameter $2. There is no need for Collection<>(Bag.T) to be a different type to Collection<>(Set.T); the simpler specialization Collection<>($0) will do. This is particularly beneficial for LambdaTypes that have many identical usages in iterator bodies for slightly different collections. TypeId-wise each identical usage has an identical TypeId.

If we emulate an operation parameter, we separate concerns and need:

TemplateParameterType that is a Type with a TemplateParameter list index.

TemplateParameter that is a TypedElement with a name, a TemplateParameterType type, and a lowerBound type.

[eclipse-ocl-bot]

By Ed Willink on Aug 10, 2022 06:27

(In reply to Ed Willink from comment #0)

There is no need for Collection<>(Bag.T) to be a different type to Collection<>(Set.T); the simpler specialization Collection<>($0) will do. ... TemplateParameterType type, and a lowerBound type.

This proves to be pretty painful. There are too many places where normalization to $1 is required or denormalization is required to find the lowerBound.

We seems to be digging a deep hole to avoid fixing an inadequate TypedId computation. The modest savings in the serialized orphanage size do not seem worth the pain.

Bottom line: Is Set a different type to Set? Yes.

[eclipse-ocl-bot]

By Ed Willink on Aug 24, 2022 04:57

(In reply to Ed Willink from comment #1)

We seems to be digging a deep hole to avoid fixing an inadequate TypedId computation. The modest savings in the serialized orphanage size do not seem worth the pain.

Back full circle. Allocation of a (Class)TemplateParameterId is no problem. It is (Operation)TemplateParameterId that is difficult since an OperationId uses a ParametersId that may use an (Operation)TemplateParameterId that uses the OperationId. Normalizing the (Operation)TemplateParameterId broke the circle.

Rather than normalizing all (Operation)TemplateParameterId we can get away with just using a normalized entry in the ParametersId and since ParametersId is used solely for uniqueness, we should never need to denormalize.

---

The problem was a very inadequate SpecializedClass/.../Id and a failure to use the Generalized as part of the TemplateParamterId. Prohibiting variant-template operation overloads ensures that the operation TemplateParameterId is just a name child of its OperationId.

Still need the type distinction.