There is a few points I disagree:
> <snip>
> } else if (elementType == this.metaTypes.getTemplateParameter()) {
> // TODO: the type of the model element used in a type parameter
> // (ie the formal) needs to match the actual parameter that it
> // gets replaced with later. This code is going to restrict that
> // to always being a Parameter which doesn't seem right, but I
> // don't have time to debug it right now. - tfm - 20090608
> Parameter param = getCore().createParameter();
> param.setName("T"); // default parameter name
> element =
> modelImpl.getCoreFactory().buildTemplateParameter(container,
> param, null);
> } else {
> </snip>
>
> The TemplateParameter is created containing a parameter which in the
> case of the code above is a Parameter
>
> I think this is pretty much correct apart from the fact that the model
> element type of the "parameter" is hard coded to Parameter. See Toms
> comments in the code and this snippet below from page 69 of the spec.
>
> <snip>
This code was wrong, I have removed it but it was restored to serve as a start
point.
Now we understand that "Parameter param" should not serve as a template
parameter
( and Tom comment just was about it by the way).
I also read the spec and what I think.
You and me are "blinded" by Java because in Java there is no other template
parameters
except abstract Classifier. Then when we use parameterized class we specify
existent class or interface (as template parameter binding).
Also in Java default elements for template parameters are not used at all.
But imaging the language where for example Integer may be used as a template
parameter.
It is not Java case, it is impossible in Java, but let it be for a moment.
Then when we use parameterized class we must specify the instance of Integer
(as a
template parameter binding) as we earlier specified existent class or interface
as
an instance of classifier. And here is a place where default values come to
scene.
We may set for example 0 or 1 as a default value for Integer instance. Obviuosly
we may specify some expression which return Integer too. That is why I said
default value should not have drop down list, or at least this drop down should
be restricted to template parameter type (Integer in our case).
> A template element has the templateParameter association to a list of
> ModelElements that serve as its parameters. To avoid
> introducing metamodel (M2) elements in an ordinary (M1) model, the
> model contains a representative of each parameter
> element, rather than the type of the parameter element. For example, a
> frequent kind of parameter is a class. Instead of
> including the metaclass Class in the (M1) ordinary model, a dummy
> class must be declared whose name is the name of the
> parameter. This dummy element is meaningful only within the template
> (it may not be used within the wider model) and it has
> no features (such as attributes and operations), because the features
> are part of an actual element that is supplied when the
> template is bound. Because a template parameter is only a dummy that
> lacks internal structure, it may violate well-formedness
> constraints of elements of its kind; the actual elements supplied
> during binding must satisfy ordinary well-formedness
> constraints.
> </snip>
>
> I think the parameter is the "dummy" element being discussed here
In java RE module I placed more correct code to build template parameter in
Java:
Object type = Model.getCoreFactory().buildInterface(templateParameterName);
Object templateParameter =
Model.getCoreFactory().buildTemplateParameter(modelElement, type, null);
Model.getCoreHelper().addTemplateParameter(modelElement, templateParameter);
Here we create dummy interface and use it's
name as a template parameter name. We need dummy element for Classifier
because it is an abstract class. We don't need dummy element for Integer if
we choose Integer to be template parameter.
So in common case we should choose the type of template parameter.
That is why we need a combo box here with available types.
For Classifier type we are to create a dummy class/interface and then
use it as a template parameter.
> 3. defaultElement
> =============
> This is shown in the spec as being any other model element in the
> model. Taking the ArrayList<T> example once more we could say that as
> T is a classifier then defaultElement can be any specific instance of
> a classifier such as Object.
>
> So I think this should be a combo where the type selectable should be
> the same type as the parameter. In other words if the parameter is a
> classifier then then defaultElement combo is a list of all classifiers
> in the model.
Except the special case when template parameter is a dummy class/interface
default element should be an expression of type equals template parameter type.
In the simplest case it may be a model element of template parameter type.
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2430082
To unsubscribe from this discussion, e-mail:
[[email protected]].
To be allowed to post to the list contact the mailing list moderator, email:
[[email protected]]
