Re: [mdt-ocl.dev] MDT OCL Behavioural customisation

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Adolfo

This is why I wanted clarity on what MDT OCL 1.4.0 is before agreeing to have one at all.

MDT OCL 1.4.0 is a maintenance release that maximises the preservation of the MDT OCL 1.3.0 interpretation of the MDT OCL 2.0 specification.

This discussion is in danger of getting confused between languages and their implementations, so I'll first enumerate the languages
(using EOCL rather than MDT/OCL when referring to the language first realised by a MDT/OCL release).

OCL '2.5' - a future implementable specification that is free of contradictions and ambiguities (utopia).
EOCL 3.0.0 - an imperfect best endeavour to make at least OCL 2.1 implementable
OCL 2.1 - the unimplementable proposed specification
EOCL 1.3.0 - an imperfect best endeavour to make OCL 2.0 implementable
OCL 2.0 - the unimplementable current specification
OCL 1.x - obsolete OCL specifications

MDT OCL 1.3.0 implements the EOCL 1.3.0 language. MDT OCL 1.4.x and 1.5.x and so on will continue to implement the EOCL 1.3.0 language, almost
certainly with exactly no change. Changes will just track evolution of EMF and Eclipse.

In fixing the invalid/OclInvalid confusion in EOCL 3.0.0 we were not responding to OCL 2.1, we were recognising that EOCL 1.3.0 was not compliant
with the most coherent interpretation of the OCL 2.0 specification. EOCL 3.0.0 is a better endeavour at implementing both OCL 2.0 and OCL 2.1.

In MDT OCL 3.0.0 we have a major increment that allows us to break APIs within reason and to correct inappropriate semantics by pursuing
the new EOCL 3.0.0 semantics that endeavour to predict what will be OCL '2.5' without limited concern for any mistakes that were made in the
EOCL 1.3.0 prediction. In so far as EOCL 3.0.0 purports to be a specific release, we should try to do other releases too. For 'static' this is easy.
For Collection conforming to OclAny, this may be much harder, so here I feel we should do the new OCL 2.1 behaviour and then consider whether
we can support the older OCL 2.0 semantics and then consider whether we can also support the EOCL 1.3.0 historical semantics. (I doubt that
we will ever have any enthusiasm to support OCL 1.x semantics.)

NB
One MDT OCL 3.0.0/1.4.0 incompatibility lies in Java implementation API changes.
another MDT OCL 3.0.0/1.4.0 incompatibility lies in EOCL 3.0.0/EOCL 1.3.0 semantic changes.
Neither of these changes need have anything to do with OCL 2.1/2.0.

NB also, that we have some freedom now to make EOCL 3.0.0 noticeably more correct than EOCL 1.3.0.
After Helios, we will be more constrained and have to balance preservation of incorrect EOCL 3.0.0 behaviour with changes to better approximate a clearer OCL specification. We must therefore try very hard pre-Helios to predict OCL '2.5' as accurately as possible so that next year we can justify all changes as obvious bug fixes.

If possible, I feel we should try to have no EOCL 3.0.0 source incompatibilities for any OCL 2.x  and so should endeavour to support all OCL 2.x in MDT OCL 3.0.0.

    Regards

       Ed Willink

Adolfo Sanchez Barbudo wrote:

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