[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[mdt-ocl.dev] Progressing the Old Code Base
|
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