eclipse-ocl-bot
commented
3 weeks ago By Ed Willink on Jun 10, 2015 18:51
API compatibility is a bit constraining.
In principle:
EvaluationVisitor is stateless, or rather caches invariant state.
EvaluationEnvironment is the stacked state.
'Executor' is the supervisor.
But we must keep the Evaluator interface for both 'Executor' and EvaluationVisitor so there is rather a lot of deprecated duplication.
| --- | --- | | Bugzilla Link | 463313 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Mar 27, 2015 13:01 EDT | | Modified | Jun 26, 2015 09:08 EDT | | Reporter | Ed Willink |
Description
The exact roles of Evaluator/EvaluationEnvironment/EvaluationVisitor are unclear. This introduces undue complexity for the OCL/QVTi debuggers with Nested variants for all three classes.
Introduction of a PartialEvaluator for QVTi will again suffer from the vagueness.
Suggestion:
Evaluator is the one overall supervisor of an evaluation. It has global/current state. Nested Evaluators are not normally used.
EvaluationEnvironment is a nestable state maintained as a daisy chain with the Evaluator maintaining the top EvaluationEnvironment which may be pushed/popped.
EvaluationVisitor is the extensible per-AST node visitor strategy. This has only one state element; the Evaluator context from which EnviriobmentFactory etc are accessible. Nested/Decorated EvaluationVisitor can go obsolete is each visit goes via the evaluator. The 'undecoratedVisitor' therefore moves to the Evaluator.
Tracing no longer needs to overload every single visitXXX method in a delegating visitor. Rather a derived TracingEvaluator can override just visit().