Re: [mdt-ocl.dev] Impact Analyzer and the Standard Library Model

[ed@xxxxxxxxxxxxx]

Hi Axel

The mature evaluator has 100% Java operation bodies embedded in switch
statements and helper functions.

The pivot evaluator has 100% Java operation bodies referenced one class
per operation from the library model.

No change for the Impact Analyzer.

One day when the Java code generator is really good, OCL bodies might be
executed, but since the bodies are small and already written, I would
expect that human code will be better, so generated bodies are more likely
to be appropriate for back-to-back testing of manual Java and generated
Java.

In a future phase of code generation development, simple functions might
be inlined, in which case OCL bodies might be exploited by the inliner.

I'm not sure why OCL bodies should be a problem. The IA can understand
them accurately whereas Java bodies presumably require custom treatment.

Ah! rereading: I read ridded as a typo for riddled.

Many collection operation could have sensible bodies. I'm not clear that
the OCL body of Real::+(Real) and many other numerics is very helpful. Any
operation for which you can provide a sensible body could have one, at
least in the Eclipse OCL library. Whether the body should become part of
the OMG OCL Standard Library is less clear; helpful is good; prescriptive
is bad.

    Ed



> How will the new OCL Standard Library model capture the bodies for the
> OCL-specified library operations? At least for those specified in OCL,
> the Impact Analyzer could be ridded of its special rules used in their
> analysis. Of course, natively implemented and prominent operations will
> still need special treatment.
>
> Summarizing the question: what't the metamodel for the standard library
> model including the operation bodies use in it?
>
> Best,
> -- Axel
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
>