[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] MDT OCL Behavioural customisation
|
Ed,
I can't make heads or tails from your last mail. We already have enough
TLAs not to try and invent some more. What is your EOCL? What could
possibly mean "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." to take an example?
In wait for clarifications of your mail, I'm more inclined to go in
Adolfo's direction : we agreed on releasing MDT OCL 1.4 so that adopters
needing OCL 2.0 compliance (or maintain compatibility) could rely on
this release until they're ready to move on to the newer (and hopefully
better) specification. We should stop implementing OCL 2.1 changes while
keeping OCL 2.0 in mind to avoid providing endless parsing options and
clutterring the code with ifs. It will still be time later to see if we
should provide compatibility options within the parser. For now, helios
is coming, and we want to have the OCL 2.1 specification implemented at
best; I believe that trying to maintain compatibility will only make a
partly implemented/buggy MDT OCL 3.0.
Laurent Goubet
Obeo
Ed Willink a écrit :
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 <mailto: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 <mailto: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
------------------------------------------------------------------------
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
