Setting attribute type to a generic type needs params

[thomas.beale]

When setting an attribute or association to refer to a generic class, e.g. I have one called Interval <T: Ordered>, then I need to be able to set the type of the attribute to a type based on this class, e.g. Interval <Date> assuming Date inherits from Ordered. At the moment this does not seem to be possible.

[Bruno Pagès]

there are several ways to do that, here like in other cases when you don't know how to model something I encourage you to write a C++ example doing what you expect, then to reverse it and to look at the result.

typically in that case you can say the type of the attribute/relation is Interval then modify the C++ definition of the attribute/relation changing ...${type}... by ...${type}<Date>... (in case of an association you can also use ${association} to specify Date).

[thomas.beale]

Ok, but I don't want to use C++ or Java or any programming language, I just want to specify something like (in the tool - here just using language to show the idea):

class XXX
property time_period: Interval < DateTime>
end

where we assume Interval <T: Ordered> is already defined elsewhere in the model, and also DateTime and Ordered are defined, and DateTime inherits from Ordered.

- thomas

[Bruno Pagès]

in this case just set the type of the attribute to be the string Interval < DateTime> (you can enter any string as the type of a property in the UML tab, you are not limited to the list of values proposed by the dialog).

[Bruno Pagès]

Here is a new proposal.

The generic type instantiation is 'fully' managed for the inheritance, I mean when editing the inheriting class the actuals are set through the tab 'instantiate' and the bindings are visible on diagram when the inheritance is supported by a realization (rather than a generalization) :

bindings

TB.png (7.32 KiB) Viewed 11178 times

corresponding to the C++ definitions :

template<class X, class Y = float>
class CGen {
};

class C : public CGen<int> {
};

using TC = CGen<C, string>;

template typedefs is a feature introduced by C++11, they are managed by Bouml 5.1 (implemented but not yet delivered)

The new proposal is to manage the binding in a similar way for the other relations and attributes, this means to add an optional 'bindings' tab in the attribute dialog when the type is a generic class, to add one or two tab(s) 'bindings' in the relations dialog when the class(es) is/are a generic, and to show the binding(s) under an option in the class diagrams.

Do you agree with that ?

[thomas.beale]

Broadly yes. It's annoying for you guys writing the tool but there is no escape from generic types! Right now the tool generates improper output (at least for the XMI) when a generic _type_ is declared. Note that the definition of a generic class is not the same as a _declaration_ of a generic type based on it.

E.g. the class

Array <T> can be defined.

Elsewhere when I define an attribute or property, I may want to declare a new type based on the class Array<T>, e.g.

class Person
names: Array<String>

Here 'Array<String>' is a new type.

Personally I would avoid relying too much on the C++ concept of templates as a basis for generic types. Like Multiple Inheritance, C++ really got some OO basics totally wrong... even if it is a powerful language! I originally programmed in ANSI C for many years, but moved to Eiffel, which still (after 20 years) has the only proper working version of both Generic types and MI. Pity it's not the main language today...

- thomas

[Bruno Pagès]

I don't understand your answer. If you want to define a new type being Array<String> this is already possible and I don't need to do the lot of changes I proposed in my previous answer. In the same way Broadly yes is not very engaging regarding on the number of changes to do ...

[thomas.beale]

Sorry, I will try to be more specific.

ATTRIBUTES
Let's say I am defining the attribute time_validity on class CONTACT in my model. I choose from the drop-down for the type and get DV_INTERVAL; it displays DV_INTERVAL [org::openehr::rm::data_types::quantity] in the type box. Now, unless CONTACT itself is generic and has an open generic parameter T, DV_INTERVAL on its own is not legal as a type; I have to be able to to specify the type parameter. In this case, since DV_INTERVAL is defined to have its type parameter T constrained to DV_ORDERED, then when defining time_validity in CONTACT, I should have some drop-down somewhere that only gives me DV_ORDERED and descendants as possibilities.

In general, since the generic type may have more than one parameter type, there needs to be a drop-down (or other choosing method) for each parameter. Now, I think you would be 99.999% safe assuming a maximum of two generic parameters - but two is common, e.g. Hash <T, K>.

Now, since you don't know in advance that I am going to choose a generic type as the type of an attribute, you have to do something dynamic on the form. Maybe posting a dialog containing dropdowns for each parameter.

When the choosing is finished, the final type constructed should be displayed, in this example able, it is DV_INTERVAL<DV_DATE_TIME>.

PROPERTIES
The semantics are all the same as above, but the UI interaction is obviously different. Let's say I draw a property line from CONTACT to DV_INTERVAL; maybe the tool prevents me from doing this. I have to create a type with the right binding, i.e. DV_INTERVAL<DV_DATE_TIME>, linked by <<binding>> to DV_INTERVAL<T>. Then I do a normal link from CONTACT to that. I think all you need to do here is to a) prevent a link going to a generic class from a non-generic class and b) enable the addition of bound classes with one or more of the generic parameters bound (remember, in general, they don't all have to be bound - you could define Hash<T, String> which would be Hash tables with string keys).

Hope this helps.

- thomas

[Bruno Pagès]

ATTRIBUTES
...I should have some drop-down somewhere that only gives me DV_ORDERED and descendants as possibilities.

I will probably not constrain the list of proposed classes, first I have to also propose classes declared 'external', and second I have to also manage constraints on target languages and the constrains for C++ and Java are not the same

Now, I think you would be 99.999% safe assuming a maximum of two generic parameters - but two is common, e.g. Hash <T, K>.

I must manage all the cases, I can't do a tool based on that kind of assumption, and let's note for example std::map has 4 parameters

PROPERTIES
Let's say I draw a property line from CONTACT to DV_INTERVAL; maybe the tool prevents me from doing this.

no, if I start to open a confirm box each time you add this kind of relation the users will be quickly very nervous

I have to create a type with the right binding, i.e. DV_INTERVAL<DV_DATE_TIME>, linked by <<binding>> to DV_INTERVAL<T>. Then I do a normal link from CONTACT to that. I think all you need to do here is to a) prevent a link going to a generic class from a non-generic class and b) enable the addition of bound classes with one or more of the generic parameters bound (remember, in general, they don't all have to be bound - you could define Hash<T, String> which would be Hash tables with string keys).

I don't see the interest of these two steps, and to not have the same rule for relation and attributes is perturbing, furthermore this is not consistent with the inheritance between classes.

so I stay on my previous proposal

[thomas.beale]

Well the underlying semantics need to be the same, that's for sure (in fact I think the whole distinction in UML between properties and attributes is ridiculous... but that's another discussion). But I don't see how you are going to avoid different user interactions for the two.

Anyway, I don't mind how you do it, as long as it works properly!

- thomas