QVT13 — QVTo: Typedef

Creating aliases seems to be a good idea specially when dealing with complex types. However, for that purpose, it is not clear to me that we need to create a (useless) typedef just to represent an alias in the concrete syntax. In practice aliases are very useful when writing transformations (in concrete syntax), but they are useless in the abstract syntax (extra unnecessary classes in modules). One may still think that a typedef as an alias (no extra condition) may be needed to add operations to existing types, as specification suggests doing in order to include new operations for the OCL standard library predefined types. However, this still can be done by means of helpers. Suggestions: - Remove the statements related to aliases in the section 8.2.2.24 - Make Typedef.condition reference be mandatory in Figure 8.7 since, now, Typedef in the abstract syntax will be used to constrain existing types. - Add statements in the concrete syntax section, to clarify the use of aliases to rename existing types. Maybe, a new keyword (like alias) could be included to avoid confusions with the typedef one. - Change the grammar to adapt it to these suggestions. - Clarify in the Standard Library section that helpers will be used to add new operations to the OCL Std Lib predefined type.

Typedef aliases issue

Creating aliases seems to be a good idea specially when dealing with complex types. However, for that purpose, it is not clear to me that we need to create a (useless) typedef just to represent an alias in the concrete syntax. In practice aliases are very useful when writing transformations (in concrete syntax), but they are useless in the abstract syntax (extra unnecessary classes in modules). One may still think that a typedef as an alias (no extra condition) may be needed to add operations to existing types, as specification suggests doing in order to include new operations for the OCL standard library predefined types. However, this still can be done by means of helpers. Suggestions: - Remove the statements related to aliases in the section 8.2.2.24 - Make Typedef.condition reference be mandatory in Figure 8.7 since, now, Typedef in the abstract syntax will be used to constrain existing types. - Add statements in the concrete syntax section, to clarify the use of aliases to rename existing types. Maybe, a new keyword (like alias) could be included to avoid confusions with the typedef one. - Change the grammar to adapt it to these suggestions. - Clarify in the Standard Library section that helpers will be used to add new operations to the OCL Std Lib predefined type.

Discussion

Ignoring the QVT Standard Library usage eliminated by the resolution of Issue 13252, http://solitaire.omg.org/browse/QVT13-13, there are two distinct usages of typedef.

a) to create an alias
b) to create a new constrained type

Discussion - alias

If an alias introduces a new type as the inheritance of Typedef from Type would suggest, we have semantic nightmares. Which type conforms to which? How do we ensure that all functionality understands the typedef equivalence? As observed, a typedef is a concrete syntax text macro that should be eliminated during conversion to the abstract syntax to avoid ambiguities. However an AS concept is needed to persist the macro. A Tag is sufficient.

Discussion - constrained type

The typedef syntax with a constraint introduces a new type. However all the important semantics of this type are unspecified. What are the superclasses of this type? What does it conform to? How do its operations and properties interact with the unconstrained type? Can a Constrained Integer be used as a Sequence index?

The only example of a constrained type is:

typedef TopLevelPackage = Package [container()=null];

suggesting that perhaps self is to be interpreted as the type instance. If container() is the proposed oclContainer() then the example is particularly interesting. If a TopLevelPackage is assigned to a container, how does the type change? Are all assignments supposed to have a predicate evaluation to ensure that typedef constraints are not violated? Are assigned types to be changed by an assignment? Does an assignment that violates a constrained type constraint render a transformation invalid and require some form of failure?

Look at it another way. Suppose we used bland UML. We can add an invariant to a class, which can inherit/aggregate another type to re-use it. We and general purpose tooling understand these semantics. What does a typedef constrained type offer that is new? just magic undefined semantics that cannot be used with any non-QVTo tool.

The constrained typedef appears to be a clear case of misguided syntax sugar. If metamodeling syntax sugar is really needed, let it have a clear relationship to UML.

Conclusion

The alias usage is a concrete syntax synonym that has no need of a Typedef class; a Tag will do.

The constrained type is underspecified syntax sugar. The Typedef class can be deprecated.

FWIW: neither of these forms of typedef is implemented by Eclipse QVTo.