Community
Participate
Working Groups
The type template parameters T and T2 from the OCL standard library are not available for operation declarations. Sometimes it would be convenient to declare an operation for a certin supertype (e.g., for all model element types), receiving back the same type as supplied: helper Element :: help() : T { ... } Is there a reason for this restriction? Simply disabling the syntax error seems to give very usable results. What are the future plans for OclSelf?
Bottom line: OCL 2.0...2.4 makes no mention of support for templates other than to be UML-aligned. The "T" and "T2" magic names are a documentation idiom to describe externally defined types used by library operations. They are an intuitive workaround for the lack of templates. The Classic Eclipse OCL on which Eclipse QVTo is based has a pragmatic magic for "T" and "T2" that does not extend to use by users. The Pivot Eclipse OCL has significant support for UML templates. There is no magic T or T2. Rather the library is defined using genuine templates. OclSelf is my innovation to enable the dynamic type of an operation to be used in a static signature. It seems to work. Contrast OclAny's operation "="(object2 : OclSelf) : Boolean[1] with Java's Object::equals() that fails to ensure a useful derived RHS. But behind the scenes the type system is more complicated. In order to avoid loss of static typing from e.g. oclAsType(MyClass), the AST elements have both a TypedElement::type, which might be typeof(T), and a TypedElement::typeValue when T is statically known. operation oclAsType(TT)(type : typeof(TT)) : TT I originally emulated Java with a Class(T) which offered huge amounts of flexibility/complexity to solve a couple of minor modeling difficulties. The typeof(T) declaration has the same effect without all the redundant power/complexity. When I have time to complete the modeling of OCL and QVTr and QVTc (and QVTo) I will be able to auto-generate substantial parts of a next generation OCL, QVT specification. This will likely include OclSelf as part of the library definition and part of the operation overload resolution mechanism. When Eclipse QVTo moves to Pivot OCL, templates will be there almost for free. --- Retrofitting templates, or a magic "T" to Classic OCL-based QVTo would be quite hard. I suspect that a variety of public APIs would need revision pretty much mandating that QVTo takes a private clone of Classic OCL. Cloning avoids the OCL API compatibility issue, but creates an even bigger QVTo API compatibility issue. If you have the significant time required to work on this, I recommend focusing on Pivot OCL, where the many design issues that arise from the extended type system have promising solutions.
