eclipse-ocl-bot
commented
1 week ago By Ed Willink on Jul 20, 2022 03:49
(In reply to Ed Willink from comment #0)
TemplateParameters can only be bound to Classes in the normalized pivot; the UML binding to a DataType should be normalized as a construction argument.
A Class specialization rewrite is just a matter of assigning the properties with constants for DataTyped values, variables for Class-typed parameters. i.e. DataType-typed parameters are rewitten as Class properties.
An Operation specialization is perhaps just a redirection of an implementation with just Class-typed parameters to an underlying implementation with additional DataTyped constants. i.e. DataType-typed parameters are rewritten as Operation parameters.
?? Package DataType-typed.
?? a TemplateableElement has a constant value for each DataType-typed parameter
| --- | --- | | Bugzilla Link | 580407 | | Status | REOPENED | | Importance | P3 normal | | Reported | Jul 20, 2022 03:12 EDT | | Modified | Jun 10, 2023 04:41 EDT | | Blocks | 509309 | | See also | 578117, 580511, 581860 | | Reporter | Ed Willink |
Description
The current TemplateParameterSubstitution / TemplateBinding design follows UML with a simplification to just Type parameters. Oops Collection is now Collection<T,Boolean,Integer,UnlimitedNatural>, see Bug 578117.
The nested TemplateBinding to persist the hierarchy of Package/Class/Operation template parameters is bloat. Let the bound TemplateParameters be flattened.
The flexibility of TemplateParameterSubstitution to support non-positional bindings is useless. Let the bound values be ordered in accordance with the flattened TemplateParameters.
NB The TemplateParameterSubstitution 'actual' is a Class for the normal Class Parameter case, but may be any value (i.e. Object) for the DataType case.
Consider a BookRole<Book-instance,Collection> for which Book-instance, may be a Book instance, e.g. "St. James Bible" and Collection may be a collection of translations/editions/... what would be the syntax for Book-instance rather than Book?
Surely this is stupid. Simpler to do.
class BookRole {\ property theInstance : Book;\ property derivations : Collection(Book);\ }
But is 'simpler' necessary?
If it is necessary for Class instances, why isn't it necessary for DataType values too?
class MySet {\
property elements : Set(T);\
property nullFree : Boolean;\
property lower: Integer;\
property upper: UnlimitedNatural;\
}
Migrating to Set<T,Boolean,Integer,UnlimitedNatural> seems like a mistake. TemplateParameters can only be bound to Classes in the normalized pivot; the UML binding to a DataType should be normalized as a construction argument.