Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[] 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.


        Ed Willink

Back to the top