| Re: [mdt-ocl.dev] MDT OCL Behavioural customisation |
Hi AllAdolfo: Now I'm getting confused. Our differences are very subtle, if any. I thought for a moment your email was written by me (your English is really good now).
Alex: There is no OCL_2_1 option. I was hypoithesing a mechanism for feature set selection..
Laurent: I'll try to explain carefully using Java and JDT as an example. EOCL is Eclipse OCL.
All: Can we please try not to mention MDT OCL 1.4.0. We all agree that it is a no-development maintenance release of MDT OCL 1.3.0. Every claim that it implements OCL 2.0 is liable to provoke further needless confusion and anguish. MDT OCL 1.4.0 exhibits source, API and binary compatibility with MDT OCL 1.3.0 that implemented an interpretation of OCL 2.0.
-------The Java language is defined by Sun and has a number of major versions 1.0, 1.1, 1.2, 1.3, 1.4, 5.0, 6.0. These each represent a different language, albeit with, in some cases, very minor differences and considerable compatibilities.
The Java language is implemented by a variety of vendors; at least Sun and IBM and Eclipse/JDT. The Java language specification is sufficiently good for vendors to attempt an exact implementation. OCL is not, so MDT OCL defines a new language influenced by an official one. Therefore OCL 1.0, 2.0, 2.1, EOCL 1.3.0, EOCL 3.0.0 are all names of different languages.
JDT provides new versions every year, so both JDT 3.4 and 3.5 provide implementations for Java 6.0.
In order to assist users who are obliged to continue using an old JVM, JDT supports a binary compatibility option so that an old JVM dialect can be chosen for newer code.
Similarly, in order for users to continue using an older coding style, JDT supports a source compatibility option.
Occasionally as with 'assert', Java introduces a backwards incompatible language change. JDT therefore provides a finer grained option to control treatment of the assert keyword.
Sometimes certain coding idioms are recognised to be dangerous: for instance "if (a = b)", so an optional warning is provided.
My support for 'static' selection has some similarities to JDT's support for 'assert'.
My support for and/xor/precedence has similarities to JDT's "if (a = b)" warning.
My suggestion of a OCL.setOptions(env, ParsingOptions.OCL_2_1) has similarities to a JDT source level compatibility setting.
-------The major difference between MDT OCL's support for OCL and JDT's support for Java is that the Java specification has sufficiently few ambiguities and contradictions to be implementable. Java also has a reference implementation and a high level of interaction amongst implementers to resolve any issue that arises. A revised Java implementation is also available with many stages of alpha and beta release for public comment. A revised OCL specification is endorsed without prototyping and with very limited review. An OCL issue may remain without comment for over a year. There is no mechanism for achieving a rapid consensus on how an OCL specification problem should be resolved.
Eclipse MDT OCL appears to be a good candidate for a reference implementation. As such we can almost impose de facto resolutions to specification problems that we become aware of. We must lead responsibly, since there is nothing/noone else to follow.
Since OCL 2.1 could be such a poor specification in detail, possibly worse than OCL 2.0, we cannot possibly claim to implement OCL 2.1 or 2.0. We implement EOCL 3.0 whose definition is OCL 2.1 revised by Issues {xxxx, yyyy, zzzz}. It would be nice to get the OCL 2.1 source so that we can distribute a coherent revised text; not on an Eclipse Site no doubt for Copyright reasons.
When offering our implementation of EOCL 3.0, we can choose what level of support to offer to users expecting to see OCL 2.0 or 2.1 or ...
I want to help users of EOCL 3.0 upgrade from 'OCL 2.0' by issuing a warning when they have an expression whose meaning in OCL 2.1 is different from OCL 2.0. This is the WARN_OF_XOR_OR_AND_PRECEDENCE_CHANGE option. It instructs an OCL 2.0 source user to add parentheses to enforce a preserved meaning. It instructs an EOCL 3.0 user to add parentheses to enforce a preserved meaning when re-using the OCL in an 'OCL 2.0' tool. Adding this ParsingOption was quite easy and localised.
I want to help users of EOCL 3.0 to prepare code for use in an 'OCL 2.0' tool. As well as the above, the SUPPORT_STATIC_FEATURES provides an EOCL 3.0 user with a warning if they use a feature that should not work under 'OCL 2.0'. Adding this ParsingOption was quite easy and localised. Taking this further to support 'OCL 2.0' behaviour in which 'static' was no longer a reserved word and so could be a variable name is dsirinctly harder and while desirable, I agree with Adolfo that we do not need to do it because we are focussed on 'OCL 2.1'.
I would like to help users accommodate the Collection conforms to OclAny and related semantic changes. However this change is not localised wrt the current MDT OCL code, which appears to have a large number of Collection, Invalid, UnlimitedNatural type conformance problems, some resulting in CCEs. Therefore for this change, I recommend that we refactor the code to provide a clean implementation of the 'OCL 2.5' semantics. When we have done this, we may find that it is possible to introduce a localised 'OCL 2.0' semantic warning, if so, let's do it; if not, too bad.
So where we can easily provide migration assistance let's do so. Where it is too hard, we can at least defer it.
I feel that MDT OCL 3.0.0 should offer the best possible interpretation of OCL 2.1. This is the EOCL 3.0 language.
Where practical, I feel that MDT OCL 3.0.0 should offer source level migration assistance to and from OCL 2.0.
Regards
Ed Willink