Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Progressing the Old Code Base

Sorry, this in inacceptable. There are two obvious bugs that were easy to fix. I provided patches for them that are fairly small, particularly since the lion's share are the additional tests. There are no regressions with the current test base. You can't force tons of new requirements on anyone as a reason not to review a bugfix.

-- Axel

On 4/13/2011 7:38 AM, Ed Willink wrote:
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
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
_______________________________________________ mailing list

Back to the top