Community
Participate
Working Groups
Function has its own queryExpression and an inherited bodyExpression. Eliminate one. In the interim, prefer queryExpression and re-implement bodyExpression as a redirect.
Closely related is the lack of a source for a Function call. This can evolve to a VariableExp to the Transformation's 'this', but we need backward tolerance for a while.
It's not so simple. Function is a comparatively simple class that always has its body represented by an OCLExpression AST. Operation supports UML's optional textual Opaque representation that needs a type-system (EnvironmentFactory/MetamodelManager) to parse. --- An Operation needs an ownedBody for the OCLExpression AST and an ownedSpecification for the ExpressionInOCL/LanguageExpression textual spec. The declared LanguageExpression lazily promoted to an ExpressionInOCL was a solution to lazy evolution without external change. But all the extra ExpressionInOCL context is bloat. Perhaps we need an intermediate between ExpressionInOCL/LanguageExpression that identifies the availability of an AST but redirects to the Operation for the bloat. Perhaps Operation shares a "Callable" ExpressionInOCL sub-interface. --- For now the Function_Body_481664 redirection class seems to avoid Pivot changes.
(In reply to Ed Willink from comment #2) > For now the Function_Body_481664 redirection class seems to avoid Pivot > changes. Correct operation domain usage analysis seems to need more functionality in the workaround and then a != null test fails because a workaound not null is returned. Time to fix this. (In reply to Ed Willink from comment #0) > Function has its own queryExpression and an inherited bodyExpression. The QVTb spec is clearly stupid. Choices: a) Function is a true derivation of Operation, in which case the queryExpression must be wrapped up as an ExpressionInOCL in a Constraint to work as a UML Operation bodyConstraint. In the Pivot the wrapping up as an ExpressionInOCL is sufficient. The Function queryExpression is a derived operation. b) Function and Operation are distinct Callable derivations of Feature. An extra abstract class in the Pivot. Sensible Feature features. Try a) since it is more compliant, no chnage to the Pivot.
(In reply to Ed Willink from comment #3) > b) Function and Operation are distinct Callable derivations of Feature. An > extra abstract class in the Pivot. Sensible Feature features. Revampling the Pivot to use Callable rather than Operation is unpleasant since Class.ownedOperations needs to change spelling / semantics. > Try a) since it is more compliant, no change to the Pivot. Seems to work. Bug 551822 suggests a better ExpressionInOCL refactoring.
(In reply to Ed Willink from comment #4) > Seems to work. Recoding all the setQueryExpression calls as setBodyExpression is tedious, and particularly awkward from the ATL2QVTr tx. Better make queryExpression a derived changeable that hides the synthesis of the ExpressionInOCL bloat. Minor limitation, Function.ownedParameters, Function.ownedTransformation.ownedContext must be pre-initialized. Works nicely for everything except the ATL2QVTr tx for which the requirement that the queryExpression.type is valid is not observed. Introducing a FunctionBody derivation of ExpressionInOCL can hide the invalid ExpressionInOCL.type by delegating to the bodyExpression.type. All ok. Pushed to master for 2019-12M1 Bug 551822 has further work.
