Legacy Issue Number: 13257
Source: International Business Machines ( James Bruck)
Say we want to expose a ParameterableElement as a formal template parameter.
If we want to create the following List<E>, then the template parameter would refer to some parameterable element E whose type we would have to choose (say uml:Class).
Now, say we wanted to create List< Interface >, or List < Class >, or List < DataType >. I don't think we would be able to then create TemplateParameterSubstitution for all these elements since the type of formal and actual parameters are inconsistent.
The problem is that we must pick a concrete type for that ParameterableElement - we can't for example use Classifier as the template parameter because it's abstract.
Reported: UML 2.1.2 — Wed, 14 Jan 2009 05:00 GMT
Disposition: Resolved — UML 2.2
This is a general issue with the way TemplateParameters are handled in the UML abstract syntax, and it would require
a major change in the approach to templates to resolve it in general. However, the specific (and most common) case
mentioned in the issue, that of a template for which it is desired to expose a Classifier as a parameter, is actually
covered by a special case in the specification.
In the UML 2.5 specification, subclause 9.3.3 describes the semantics of ClassifierTemplateParameters, which are
TemplateParameters where the parameteredElement is a Classifier, optionally constrained by a set of constraining-
Classifiers. Toward the end of this section, it says “if the constrainingClassifier property is empty, there are no constraints
on the Classifier that can be used as an argument.” Thus, in defining a template List<E>, it is possible for the
parameteredElement of the formal TemplateParameter E to be a Class, but to still, in a binding for List, substitute for
E with an argument that is any kind of Classifer (including Interface, DataType, etc.).
Disposition: Closed - No Change
Updated: Fri, 6 Mar 2015 20:58 GMT