> > Sounds reasonable to me; though I would personally be fine with > adding some small classes along the lines of what I outlined above > to support events. They could even be package-scoped if we want to > keep them out of the public API and replace later with more general > constructs used elsewhere in [math]. We are not talking about much > code at all here. > > I think if you are careful, you can likely set this up so that you > can continue to add features to the event framework (or even add the > framework itself) and stopping criteria without breaking backward > compatibility in 3.x releases. > > I would like to see this in 3.0 if you can get something simple > completed that can be enhanced incrementally in 3.x and possibly > refactored in 4.0. > > Phil > Of course, I'm all for it! I didn't really like this fall-back solution, which was more aimed at efficiency. I'll try to set up something and submit it to you all (drawing inspiration from the event handling in ode). Sebastien
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
