[pivot] Improve OperationCallExp etc flexibility

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 482532 | | Status | NEW | | Importance | P3 normal | | Reported | Nov 18, 2015 16:20 EDT | | Modified | Nov 19, 2015 04:25 EDT | | See also | 482093 | | Reporter | Ed Willink |

Description

OperationCallExp is awkward to extend for QVT's Function derived Operation. All dispatch is resolved by metamodelManager.getImplementation which is also awkward to extend.

Horacio observes that re-using the visitor internally so that a distinct resolution is available for each derived Operation can accommodate Function nicely.

But this is a fix for a badly designed class that does not comply with plausibly inherited WFRs. Providing the missing source makes Function redundant.

[eclipse-ocl-bot]

By Ed Willink on Nov 19, 2015 04:14

The EvaluationVisitor API is returns-a-result-Object which is not particularly meaningful for structural types such as Operation/Property/Class. Returning a LibraryOperation/LibraryProperty implementation for Operation/Property is not inconsistent, but the whole visitOperationCallExp is to do with resolve dynamic dispatch, resolve static, resolve implementation so that perhaps visitOperationCallExp should be overridden in the first place.

Perhaps visitOperationCallExp should evolve to be a framework of method calls each of which can be overridden. Thus rather than replace:

LibraryBinaryOperation.LibraryBinaryOperationExtension implementation =\ (LibraryBinaryOperation.LibraryBinaryOperationExtension)\ metamodelManager.getImplementation(actualOperation);

by

LibraryBinaryOperation.LibraryBinaryOperationExtension implementation =\ (LibraryBinaryOperation.LibraryBinaryOperationExtension)\ actualOperation.accept(undecoratedVisitor);

better to support a framework override in:

LibraryBinaryOperation.LibraryBinaryOperationExtension implementation =\ (LibraryBinaryOperation.LibraryBinaryOperationExtension)\ getImplementation(actualOperation);

This incurs only one subroutine call cost, rather than two or three for a visit. JIT might even lose the cost.

[eclipse-ocl-bot]

By Ed Willink on Nov 19, 2015 04:25

The split of Evaluator into distinct Executor / EvaluationVisitor makes the Executor another place for overrides, so perhaps the redirection of visitPropertyCallExp to\ \ context.internalExecuteNavigationCallExp(propertyCallExp, referredProperty, sourceValue);

should be emulated with some form of

context.internalExecuteOperationCallExp(...);

NB. The EvaluationVisitor is suitable for Class-specific tailoring\ the Executor is for execution-style tailoring (e.g. incremental/lazy)

The original Function/Operation anomaly is a Class-specific issue.

Perhaps both getImplementation and internalExecuteOperationCallExp are helpful.