Community
Participate
Working Groups
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<T>() 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<P>::D<Q>::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.
(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<T extends MyX> a different type to Set<T extends MyY>? Yes.
(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.
