[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] MDT OCL Behavioural customisation
|
Ed,
Yup, that's way easier to understand, thanks for the clarifications. I
still don't like this "EOCL" notion; but I understand your point. Going
towards a "best possible implementation" (your notion of "implementing
OCL 2.5") indeed seems like the best option we have, but we should also
remember that we have limited time to release MDT OCL 3.0. Of course, I
do like the idea of having compatibility options; as a developper of a
project that relies on MDT OCL, I'd like to be able to switch to the
new, better implementation without telling my adopters "Well, we
switched to the new MDT OCL, none of your expressions will compile now.
Please throw away what you've done so far and come to the new version".
I just think that with the limited manpower we have,
implementing/introducing changes for the new specification support
shouldn't involve trying to find a way to support both specification
version.
You mentionned that these two options you added were localized and easy
to implement, so this doesn't really apply : when the choice is not
tedious to implement, yes, it should be. I totally aggree with your
comment "So where we can easily provide migration assistance let's do
so. Where it is too hard, we can at least defer it.".
Among all of what need to be done for this release, I am not willing to
play with the parser (I am not familiar with grammars and parsers), so I
won't be the one to introduce these compatibility options in the end.
I'll let you determine what's too tedious and what can be done; but I
would like the option's default to always be set to the new behaviour.
That would mean : by default, don't warn for operator precedence change;
by default, support static features. If we introduce such compatibility
options, I'd also like to have a way to set _all_ options at once to the
2.0 or 2.1f that's what you suggest with the ParsingOptions.OCL_2_1
thing, I believe I fully agree with your conclusions on this last mail.
Laurent Goubet
Obeo
Ed Willink a écrit :
Hi All
Adolfo: 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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
