Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] New OCL Standard Library functions


The API 'safe' addition of library functions was not so safe after all.

Some of the functions were already implemented by QVTo which now has ambiguous definitions that fortunately are resolved with only warning messages in the editor, but lead to JUnit failures.

The String::lastIndexOf function has a 'duplicate' undocumented QVTo implementation that returns Java rather than OCL indexes.

If QVTo is to be strictly QVT 1.1, then String::+ comes from the QVT library, and OCL 2.2, OCL 2.3, 'OCL 2.5' library functions are not available. i.e. no String::at(), no String::characters() and reduced OrderedSet functionality.

If QVTo is to maintain OMG currency then String::+ etc come from OCL 2.2/2.3.

If QVTo is to maintain Eclipse currency then all the new functions can come from the OCL 2.5 candidate.


Should we do something to assist strict tooling?

The usage severity approach taken for closure() will not work for the case of migrating declarations that have become ambiguous.

For strict support we need two options that control the presence of declarations

Enable_OCL_2_2_functions declarations for String::+ etc

Enable_OCL_2_5_candidates for String::lastIndexOf, regex, etc

These are easily accommodated in the programmatic OCLstdlib builder, which is now the default. More tedious are the oclstdlib.ecore/uml pseudo-models. Might need multiple files.


This change does not seem to impact on Acceleo that is not so tightly coupled.


        Ed Willink

Back to the top