[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [mdt-ocl.dev] MDT OCL Behavioural customisation
|
+1. I am also inclined to focus on the newest specification
and to forget about OCL 2.0. IMO Options in 3.0.0 release should be used
exactly in those cases as described by Adolfo.
One
more thing,
OCL.setOptions(env,
ParsingOptions.OCL_2_1);
Why
isn't this option set by default?
Cheers,
-
Alex.
I thought that one of the reasons of shipping two builds in Helios is
to be completelly focused on 2.1 spec without being worried about any OCL 2.0
spec implication or MDT-OCL 1.3 backward compatibility.
I guess we need
Alex, laurent, ¿Kenn?'s point of view.
Sumarizing mine (anyway, please
take a look to the bugs):
Since MDT-OCL 3.0.0 is a major increment
release and we want to focus on a new 2.1 OCL spec, I'm inclined to lose the 2.0
spec perspective in order to avoid including extra logic not to lose said
perspective. We will have time to use the helpful Options, when we release 3.1,
3.2,etc to keep backward compatibility and when we include any
arbitrary-controlled-by-options decisions which may deviate 2.1 specification or
may anticipate future OMG specification's accepted
changes.
Cheers,
Adolfo.
2009/9/23 Ed Willink
<ed@xxxxxxxxxxxxx>
Hi All
In Bug 258633 I added
ParsingOptions.SUPPORT_STATIC_FEATURES to allow user customisation of the
treatment of the new OCL 2.1 'static' keyword.
In Bug 288040 my patch
adds ParsingOptions.WARN_OF_XOR_OR_AND_PRECEDENCE_CHANGE to allow user
cistomisation of a warning that OCL 2.1 and OCL 2.0 have a different
interpretation for a user's _expression_.
These options use facilities
that Christian introduced to control extensions e.g.
ParsingOptions.USE_BACKSLASH_ESCAPE_PROCESSING.
------------------
Adolfo
has expressed disquiet about this usage, so we should discuss our
policy.
------------------
My inspiration comes from
JDT.
A substantial set of preferences allows user customisation of @Override,
import, redundant null check etc.
gcc. Many extensions are
ciustomisable. +strict chooses a predefined exactly ISO specification set of
selections.
Visual C++. #pragmas allow the treatment of each warning
and error to be controlled.
-----------------
I feel that we
should give the user an opportunity to control debatable behaviour.
At
a low level each ParsingOptions controls a debatable behaviour.
At a
high level we can add a new helper function such
as:
OCL.setOptions(env, ParsingOptions.OCL_2_1);
to support
selection a standard configuration.
In GUI preference pages we can
allow non-programmatic customisation.
------------------
With
the OCL 2.0 and 2.1 specifications so contradictory, we will not be able to
achieve an unarguable
set of OCL 2.0 or 2.1 behaviours. If someone wants
compatibility with another OCL implementation
we should try to allow
tailoring.
Some syntax changes such as 'static' are very clear cut. In
OCL 2.1. Not in OCL 2.0.
Some languages changes are very naughty. The
change in xor-or-and precedence is very
clear cut between 2.1 and
2.0.
For these changes I feel we must help the user by allowing them to
configure MDT/OCL to
check that their OCL is comparible with a desired
behavioural feature set.
Regards
Ed
Willink
_______________________________________________
mdt-ocl.dev
mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
