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