Hello,
and thanks for all this work! The new framework looks great... Can't
wait to find a use-case...

2012/8/24 Gilles Sadowski <gil...@harfang.homelinux.org>:
>> [...]
>>
>> I see three different solutions for this.
>>
>> 1) don't try to merge at all, and duplicate the Newton solver with the
>>    new type.
>> 2) change the Newton solver to implement only the new interface (i.e.
>>    remove the "implements" statements for the former interfaces but
>>    let the old methods in place (they would appear as independent
>>    methods, declared deprecated)
>> 3) add solve methods with the new signature in the existing Newton
>>    solver, but do not declare them as implementation of the new
>>    interface (they would appear as independent methods)
>>
>> Solution 1 is easy but would imply a new name is chosen for the solver,
>> and would stick when the former solver is removed. Using something as
>> Newton2 may seem good while Newton is still there, but would be awckward
>> when it will be removed, so we should either choose a different name or
>> rename Newton2 into Newton later on. I don't like this.
>
> +1 but with "NewtonRaphsonSolver" as the name of the new class.
>
> ["NewtonSolver" should thus be deprecated in 3.1.]
> Users can start to adapt now and their new code will not be broken in 4.0.
>
>
> Best regards,
> Gilles
>
>>
>> Solution 2 is not backward compatible. Some users may have written
>> something like the following, which would not compile anymore:
>>   DifferentiableUnivariateSolver solver = new Newton(...);
>>
>> Solution 3 is my prefered choice, it is the opposite of solution 2. It
>> allows user to prepare using the new framework without breaking existing
>> code (at least I think). It's drawback will be that when 4.0 will be
>> released, the base class and interfaces for this Solver will be switched.
>>
>> What do you think?
>>
>> best regards,
>> Luc
>>
I'm also in favor of Solution 1, with NewtonRaphson as a name (no need
to rename in 4.0).
Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to