Ed,
I agree that we should give an OCL client to configure debatable
behaviour, but, when the debate deviates from OCL 2.1 in a sensible way
(not only for keeping compatibility with the OCL 2.0 specification).
This excludes:
- OCL_2_1 option. This is not
debatable: The MDT-OCL 3.0.0 is an OCL 2.1 implementation.
- SUPPORT_STATIC_FEATURES
option. This is not debatable: OCL 2.1 support static features, and
MDT-OCL 3.0.0 must support them without exception.
- WARN_OF_XOR_OR_AND_PRECEDENCE_CHANGE option. This is not debatable:
OCL 2.1 has changed the precedence of the operators. We must implement
the change, and adding this kind of warnings doesn't apply.
I must add that the debatable behaviour should be considered as long as
there is a feasible way to include the deviation. So, for example, the
change related to operator precedence:
- We must change the precedence of the operators as the new
specifications states. Does this change make sense ?. The debate
starts...
- We should then consider giving the alternative to modify the
behaviour of the tool, for example, give the possibility to restore the
OCL 2.0 behaviour (or include a different approach).
- Is this possible?. Can we keep different grammars and such ?.
Probably not, so we should bet for one of them. In principle I'm
inclined to be specification compliant. However, if the change is too
bad, and it's supposed to be changed again to restore (or include a
different) operator precedence, we can discuss about deviating from the
spec and implementing another alternative.
BTW, as Kenn has noted, what we should do is gathering info for a
migration help/guide so that client focused on OCL 2.0 / MDT-OCL 1.3.0
can step over OCL 2.1 / MDT-OCL 3.0.0 instead of OCL 2.0 / MDT-OCL
1.4.0 in an esasier way.
Cheers,
Adolfo.
Alexander Igdalov escribió:
+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
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
--
|
Adolfo
Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231 / +34 617 718268 |
|
