I really don't think that a general progress listener framework implies this clutter and for long running algorithms is a very nice thing. CM does not actually have all that many long running algorithms.
On the other hand, the proposed interface is not a general progress listener and is not a good idea (IMHO). On Thu, Nov 18, 2010 at 3:52 PM, Gilles Sadowski < gil...@harfang.homelinux.org> wrote: > > > > I had a very simple one-method interface in mind, namely > > > > public interface CMAESPlotter { > > void plot(List<Double> fitnessHistory, List<Double> sigmaHistory, > > List<RealMatrix> meanHistory, List<RealMatrix> > > dHistory, int lambda) > > } > > The problem is that you start cluttering the code with interfaces that are > not related to the working of a mathematical algorithm and are meaningful > only in relation to a specific part of the library. Other users would like > to access the internal state of different algorithms; so you could end up > with many such interfaces: > > interface ThisPlotter { ... } > interface ThatPlotter { ... } > interface AnotherNiceAlgorithmPlotter { ... } > etc. > > Moreover, this would make the list of contructors grow, as well as would > require additional instance variables... >