Hi. > > > > I think the opposite: IMHO, as I said above, "Base" is less redundant than > > "Abstract"; and then, the name indicates that the class is the "root" of > > the hierarchy for this functionality. > > > I also tend to think that Base or Basic is more meaningful, but any > choice is fine by me. > > > > Now, if we strive for shorter names, and it doesn't matter that developers > > would need to go to the Javadoc-generated documentation to see the parent > > relationships, I don't mind dropping both "Base" and "Abstract". Except that > > it won't be possible because there usually is an interface by that name. :-} > > Thus, as with all the other cases where we merged the interface with the > > single meaningful implementation, maybe that here too, we could dispense > > with > > the interface and have "UnivariateIntegrator" be an abstract base class... > > > I would tend to agree, except that one of the changes I would like to > suggest for future releases (4.0 ???) is revisiting the integration > package. Indeed, the way the interface is designed assumes that all > integration algorithms are iterative. [...]
This is a change which was proposed and discussed on the ML (which arguments should be passed at method call, which should be passed to the constructor, cf. the archive) considering the current set of algorithms and with an eye towards uniformization of usage across the "solvers", "optimization" and "integration" packages. > [...] maybe it's not worth spending too much time on the > interface naming just now. Probably not before a working code contradicts the current setup... Best, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
