[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] General question regarding bugs in existing impl vs. Pivot impl
|
Hi Axel
It's more than a couple. At least 50%, perhaps 90%, of the bugs I have
RESOLVED against M5, M6 are resolved by the pivot model in the examples.
They cannot be CLOSED until the resolved functionality is acceptably
available to existing users.
It was the breadth of the problems in the current implementation and the
incompatibilities of the Xtext ANTLR front end that forced me to pursue
the pivot approach. I regard solving problems such as making the
standard library extensible as alamost insoluble in the old code, where
library definitions occur not always consistently in at least seven,
perhaps nine, places. Identifying where OCL semantics such as implicit
collect, implicit as-set, conformance to OclAny, etc etc are coded is
very difficult; just look at the number of bugs related to stupid
malfunctions, particularly cast failures on numeric inequivalences. If
you want to try fixing these problems in situ, good luck, and don't
forget to do UML too. You will be in major one step forwards, five steps
sideways, half a step back country. I gave up and the pivot is the result.
If you use Acceleo and QVTo you will find a surprising number of
facilities that work correctly, even though the old code doesn't. They
have layered fixes and workarounds on top, all as part of re-using a
semi-extensible code base. When OMG recast OCL as an extensible language
and reused it, OCL implementations were left lacking. Eclipse OCL has
been very much behind the curve in supporting extensibility. My
UMLX/QVTd work pushed the grammar extensibility, but the library has
been a nightmare.
The pivot model gives us an opportunity to provide an extensible code
base with shared infrastructure for other projects. I hope you can help
me to bridge the analyzer/parser gaps between the new and the old.
Realistically, I would expect that an attempt to upgrade the old code
will involve at least a man year's effort with API compatibility fights
every step of the way. You can of course do a day here and a day there
and each is a small improvement but it ignores the big issues. This
seems to be what you're doing. I don't find it very helpful, because by
the time all the documentation and review and discussion are done, that
day costs me half a day. I would much prefer to regard the old code as
mature.
Alternatively, the pivot code is now useable, the major activities are:
- UML profiles so that the Pivot works on UML as well as Ecore (maybe M7)
- pedantically accurate rather than pragmatic UML alignment
- use of OCL rather than manual code to define scoping and CST/AST mapping
- OCL code generation
- clean clear APIs with strong similarities to the old APIs
- good documentation
- activation of the old unit tests on the new code
The third activity closes the gap with the OCL specification, so that
OMG OCL defines
- scoping (Inherited/synthesized attributes),
- CST/AST mapping the CST well-formedness
- AST validation overall well-formedness rules
With the specification gap closed, QVT will become easy as a
demonstration of extensibility.
We probably want to do some serious project planning at EclipseCon. I
will be about on the Sunday and Friday.
Regards
Ed
On 14/03/2011 22:17, Axel Uhl wrote:
Hi all,
we have a couple of occasions where a bug was reported against the
existing implementation, e.g., using the Ecore binding. Obviously,
some of them either don't apply in the Pivot implementation or have
explicitly been fixed there already.
The Pivot implementation is under examples/ for Indigo. We have to see
how promotion will work and how the deprecation process for the
currently active implementations with the uml/ecore bindings will
happen. This may also depend on the feedback on and adoption of the
Pivot implementation.
I feel that for some important aspects we should be doing
some---admittedly unpleasant---double maintenance and not simply close
bugzillas by saying they don't apply to or are already fixed in the
Pivot implementation.
I'd like to learn about your opinions on this.
Thanks and best,
-- Axel
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1204 / Virus Database: 1498/3506 - Release Date: 03/14/11
