[mdt-ocl.dev] Re: Refactoring the OCL evaluation visitor

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi

I think this goes much deeper.

We clearly have concerns about the modularity of the operation dispatch.

We have concerns about the value promotion for PrimitiveTypes and null 
and invalid.

We have concerns about the type conformance logic, particularly with 
changes for Collection and OclAny.

These can probably benefit from a coherent design revision.

Even more fundamental is a question/statement that Alex has raised in a 
couple of threads:

Does OCL support dynamic operation dispatch?

I think it should do, but I haven't combed the specifications looking 
for positive or negative
indications.

UML clearly does support dynamic dispatch and OCL is struggling for UML 
alignment.

OclAny is supposed to make Library types behave like ordinary types, so 
I think that there
is dynamic dispatch, not only of explicit UML operations, but also of 
OCL def constraints.

I think evaluation should work as if a revised UML model was created 
incorporating all the
def constraints, validated using UML model semantics, then evaluated 
using UML access
semantics.

If OCL does have fully dynamic dispatch then we definitely need dispatch 
to be model
driven to accommodate extended models.

So, does OCL support dynamic operation dispatch?

   Regards

      Ed Willink


Alexander Igdalov wrote:
> Hi All,
>
> It would be nice to make the EvaluationVisitorImpl.visitOperationCallExp()
> method less bloated.
> I agree with Laurent that #3 is the best of the three.
> Another approach (#4) would be to somehow link the evaluation code with the
> corresponding EOperation. IOW, there would be an evaluation class for each
> operation. And there would be a link (in EOperation adapters for instance)
> referring to the corresponding evaluation class. Thus, visitOperationCallExp
> will only have to delegate the call to the evaluation class referred by the
> operation.
> The question is how to correspond evaluation classes with their operations.
> We can perform these lookups when instantiating the OCLStandardLibrary.
> Actually this idea comes from QVTO where there is no ecore/uml model of the
> standard library. The standard operations are added in the Java code, i.e.
> EOperations are created by hand. The corresponding evaluation class is
> created and linked to its EOperation at the same time when the EOperation is
> created. Although it is convenient, this has a certain drawback that the
> evaluator cannot be easily separated from the compiler.
>
> Before evolving this idea I would like someone to explain me why there are
> two ways of building the standard library:
> 1) using an ecore/uml model (oclstdlib.ecore and oclstdlib.uml)
> 2) by hand in OCLStandardLibraryImpl.build()
>
> Cheers,
> - Alex.
>
> -----Original Message-----
> From: Laurent Goubet [mailto:laurent.goubet@xxxxxxx] 
> Sent: Monday, October 05, 2009 4:57 PM
> To: ed@xxxxxxxxxxxxx; Alexander Igdalov; Adolfo Sanchez-Barbudo Herrera
> Subject: Refactoring the OCL evaluation visitor
>
> Hi team,
>
> As you might have seen through the last patch I attached to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=267223 , I am trying to
> refactor the evaluation visitor so as to try and improve its readability and
> maintainability (my primary target being the visitOperationCallExp and its
> thousands lines). This is the reason why I created the test suite attached
> to https://bugs.eclipse.org/bugs/show_bug.cgi?id=287977
> in the first place.
>
> My first attempt (as per the patch attached to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=267223 ) isn't satisfactory as
> it adds new "if" statements for each different kind of operations (boolean,
> collection, String, ...) and it splits the monstruous switch statement over
> all different operation codes within multiple methods. Another approach I
> can see is to create a single "doSwitch" method which would then delegate to
> multiple "visitXxx" 
> methods; that would enhance the extensibility of the visitor for clients,
> yet that would make an incredibly large EvaluationVisitorImpl.
>
> Instead of creating these multiple "visitXxx" methods in the same visitor, I
> could also create new visitors to split each different kind of operation in
> its own : we would then have a BooleanOperationVisitor with its "visitAnd",
> "visitOr", "visitXor", ... an CollectionOperationVisitor with its
> "visitIncludes", "visitIncluding", etc. Extensibility at its best ... but at
> the price of duplicating the classes and adding visitors to the code base.
>
> All in all, I believe that having a single "doSwitch" method is a must : 
> I truly dislike switch statements, and splitting them over multiple
> methods/classes is probably the worse we could do. Yet I don't really which
> path to go down to for the remainder :
> 1- multiplying the methods of the alraedy large EvaluationVisitorImpl?
> 2- Creating a new "StandardOperationVisitor" that would contain the whole
> set of these visitXxx methods?
> 3- Creating multiple small visitors for each subset of these visitXxx
> (BooleanOperationVisitor, CollectionOperationVisitor,
> StringOperationVisitor, ...)?
>
> I would be in favor of the third option, but before I begin even trying, I'd
> like to have your opinions. Keep in mind that the main goal of this
> refactoring is to ease the maintenance, and even if I am familiar with the
> evaluation part of OCL, I probably won't be the only one
> maintaining/improving it ;).
>
> Laurent Goubet
> Obeo
>
>
>
>
>