Community
Participate
Working Groups
The fitst at attempt at OCLinEcore debugging failed because the ExpressionInOCL was unstable. The current design is a mess. Parsing creates an OpaqueExpression that is very UML compatible, with a lazily created child ExpressionInOCL if the OCL AS is required. So we have a double ValueSpecification, necessary because the EssentialOCL parser wants to create and return a new ExpressionInOCL. The Pivot does not need to be 100% UML compliant, so rethink.
The double ValueSpecification is not necessary, we just need a two-phase ExpressionInOCL. Loading UML/Ecore results in an a 'specification'; an ExpressionInOCL with an OCL-language body, but a null bodyExpression. Subsequently lazy parsing converts the 'specification' to a 'query'; an ExpressionInOCL with a non-null bodyExpression. Infortunately the 'specification'/'query' distinction is not enforceable by the type system; just strong names. So this provides some motivation for cleaning up the numerous variants of getExpressionInOCL. All existing ones go to be replaced by MetaModelManager.getQuery... A minor modification to ParserContext enables a pre-existing AS root to be made available to the parser so that an ExpressionInOCL parse can update the 'specification' to a 'query' without trashing the pre-existing object. It is not obvious that ExpressionInOCL really needs body/language arrays, but throwing away this UML compatibility might prove to be a mistake. UML-to-Pivot wise, the UML-specified OpaqueExpression is merged into ExpresionInOCL and all OpaqueExpression-valued properties reference ExpressionInOCL instead.
(In reply to Ed Willink from comment #1) > Infortunately the 'specification'/'query' distinction is not enforceable by > the type system; just strong names. The code evolved so that ExpressionInOCL extends the abstract LanguageExpression. Accesses that return a LanguageExpression have not necessarily had their OCL parsed, therefore the MetamodelManager.parseSpecification(LanguageExpression) method performs a simple down cast of already parsed, or parses and downcasts if necessary. ---- While addressing Bug 529181 inconsistent parsing was detected and all calls to parseSpecification were moved to use EnvironmentFactoryExtension2.parseSpecification pending a promotion to EnvironmentFactory.
(In reply to Ed Willink from comment #2) > The code evolved so that ExpressionInOCL extends the abstract > LanguageExpression. This has been in use for some time. Seems ok. RESOLVED FIXED. But Bug 481664 deals with difficulties in the inconsistent Function usage of a body. Bug 551822 suggests revampling ExpressionInOCL to make it more OPeration-friendly.
