Community
Participate
Working Groups
A helper without an operation body results in an NPE, which is certainly not the intended behavior. Should it return null instead? Should there be a compile error? Can the 'abstract' keyword help do distinguish legal from erroneous declarations?
Maybe the discussions on bug 428028 or bug 428189 provide some hints on how to handle this case?
Furthermore, I wonder why this case doesn't at least produce 'invalid', as intended for bug 415660. The reason is that QvtOperationalEvaluationVisitorImpl catches RuntimeException in executeImperativeOperation() and converts it into a QvtRuntimeException which bypasses the conversion to 'invalid'. I'm not sure if this behavior is appropriate.
bug 428189 discussed body-less mappings rather than helpers, but helpers too can be a polymorphic hierarchy. My normal expectation, from C/C++, is that a bodyless definition is a forward declaration that resolves parsing difficulties or an external declaration. Forward referencing is unspecified in QVTo, but many statements in OCL/QVT only make sense as the ultimate truth of the parsing/analysis, so I take the view that there is no prohibition on forward references in QVT and so no need for pre-declarations. Therefore a bodyless mapping is either a typo for a missing 'blackbox' or a typo for an empty body. Since the current behavior is NPE, backward compatibility is not a problem. Suggest: at run time, empty non-blackbox helper body returns invalid. at compile time empty non-abstract non-blackbox helper body is a warning, ideally offering 'abstract' or 'blackbox' or '{}' as quickfixes. If/when we have a strict option, change the warning to error.
(In reply to Ed Willink from comment #3) > at run time, empty non-blackbox helper body returns invalid. Except that, see Bug 440813, when used in an imperative context a to-be-specified exception should be thrown.
By the way, does OCL provide semantics for 'abstract' operations? QVTo seems not, and I still wonder if the implemented behavior for abstract mappings (i.e. may have a body, but must not be invoked directly, only merged/inherited) is profound or just a guess.
The semantics of operation overloading and dispatch are left as a variation point in UML and are not specified in UML, leaving both UML and OCL with a gaping hole. In various discussions I have found no objections to using Java-like semantics. The Ecore-based OCL has an evaluation preference to select dynamic dispatch. The Pivot-based OCL only supports dynamic dispatch, with the extra elaboration that OclSelf may be used in a type signature so that Real::"-"(OclSelf) automatiocally dispatches to Real::"-"(OclSelf) or Integer::"-"(OclSelf) according to the common type of two arguments. I hope that QVT ?2.x will clarify in similar fashion, with the slight proviso that the Package behavior of xxxTransformation may vanish in favour of a clean Class inheritance. xxxTransformation should be nested within one of more Packages to establish name qualification.
