[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[mdt-ocl.dev] New OCL Standard Library functions
- From: Ed Willink <ed@xxxxxxxxxxxxx>
- Date: Thu, 10 May 2012 07:36:33 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
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
If QVTo is to maintain OMG currency then String::+ etc come from OCL
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
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