Follow-up Comment #9, bug #39713 (project gsl):
Not if we have to maintain the existing API's since we would need s new item
in the state for the functiopn value. And if you are saying that we have to
maintain the existing API's for ever more, we cannot expect to improve GSL in
areas where experience shows that API improvments are desirable. I like the
Python approach where they are willing to break legacy code every few years in
order to accomodate improvements built on real experience (i.e GSL v2.0 would
allow API changes).
One way round the legacy issue is to have two returns from the solvers
SOLVER_SUCCESS and SOLVER_CONTINUE and to map these both onto GSL_SUCCESS for
legacy code and onto GSL_SUCCESS and GSL_CONTINUE otherwise (do we have a
define for detecting a user desire to use a legacy API?).
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?39713>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
