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

[Axel Uhl <eclipse@xxxxxxxxxxxxxxxxxx>]

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
> 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
> _______________________________________________
> mdt-ocl.dev mailing list
> mdt-ocl.dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev