[mdt-ocl.dev] Progressing the Old Code Base

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Axel

When Laurent started looking at the evaluator and providing detailed 
tests, he found a large number of corner case problems. The difficulties 
of fixing these and supporting extensibility in the absence of the 
coherence that a library model would provide, forced me to conclude that 
we needed a library model and non-conflicting UML/Ecore behaviour. This 
functionality is available now in the Pivot evaluator that integrates 
with the Xtext editors.

You have just identified a bug 342561 in the old code and upon 
investigation a further bug 342644. Neither is present in the new. This 
is typical progress for the old code base. The lack of locality and 
policy makes bugs very difficult to pin down.

If you want to progress the old code then please start a branch and 
introduce coherency to it.

At such time as the branch:
- uses a library model
- derives all usage of library operations from the model
- select alternate OCL semantics from distinct library models
- handles numeric polymorphism
- handles type expressions
- handles Collection to OclAny conformance
- has and uses a defined policy for null/invalid
- supports UML and Ecore
- supports extension libraries
- supports easy definition of new iterations as well as operations
- supports dynamic dispatch
- supports reflection (oclType)
- ....
- is highly API compatible (since it is the old code with the old 
namespaces)
I will review it.

Until then I must direct my time in the way that I feel is best for the 
project. I will not therefore review minor incremental behaviour changes 
to the old evaluator/analyzer and so, unless Adolfo has time to review 
them, the changes must go on hold till the above coherency is completed 
in a branch. Major very localized problems may still be addressable, but 
anything that involves invalid and particularly something that involves 
a new policy that then requires modification to preserve functionality 
for existing code (the impact analyzer) is just too dangerous. The 
existing code has many problems but some users are happy with it. Making 
it 10% better makes it 10% different for some existing users giving them 
problems without the justification that significant progress has been made.

So please, either work to resolve nearly all the old code base issues in 
a branch, or better, please work to enhance the new code so that we can 
minimize the impact and maximize the benefit to users when/if it is the 
preferred code base in Juno.

    Regards

        Ed Willink