eclipse-ocl-bot
commented
3 weeks ago By Ed Willink on Oct 08, 2019 13:22
Bug 481664 introduced a FunctionBody and made the tx this context a Parameter while generalising many Variable/Parameter to VariableDeclaration.
done in 2019-12M1
(In reply to Ed Willink from comment #0)
b) Let Operation inherit from ExpressionInOCL to eliminate the bloat. ?? Property too ??
b) is a simplification, but non-trivial multiple inheritance can have unpleasant corrolaries.
to do.
| --- | --- | | Bugzilla Link | 551822 | | Status | NEW | | Importance | P3 normal | | Reported | Oct 07, 2019 03:09 EDT | | Modified | Nov 09, 2022 08:18 EDT | | Blocks | 509309 | | See also | 439013, 481664, 541380, 579109, 580356, Gerrit change 196833 | | Reporter | Ed Willink |
Description
Bug 481664 struggles with the uncomfortable QVTb derivation of Function from Operation with Function attempting to have a simple OCLExpression body, while Operation emulates part of UML's bodyCondition Constraint with an ExpressionInOCL/LanguageExpression body.
In isolation ExpressionInOCL is good providing a wrapping context, but when embedded in Operation/Function it is bloat repeating the container's context.
The bloat uses ParameterVariable referencing Parameter, whicj might be necessary if ParameterVariable could be different to Parameter, but in OCL the variables are initialized on construction and are thereafter immutable. THe complexity of multi-valued nested operations is handled by using the VariableDeclaration as a key to the loval environment. ParameterVarible should not be necessary.
a) Introduce ConcreteExpressionInOCL / DelegatingExpressionInOCL derivations one with the local context, the other with the container's context.
b) Let Operation inherit from ExpressionInOCL to eliminate the bloat. ?? Property too ??
b) is a simplification, but non-trivial multiple inheritance can have unpleasant corrolaries.