Re: [Quantlib-dev] solvers in Instruments - why nested classes rather than adapter+binder?

[Luigi B. <lui...@gm...>]

On Tue, 2007-03-20 at 10:49 -0700, Chris Kenyon wrote:
> I have a question about use of solvers, e.g. in Instruments & Engines.
> In classes such as CapFloor a nested class in the Instrument is used
> to provide a function to a solver by overloading the  () operator (see
> capfloor.hpp & capfloor.cpp).   However, the same result can be
> achieved by using an ordinary method (no overloading) together with a
> binder and an adapter [...]
> 
> So why go with embedded classes?  What was the rational?

Historical reasons, I guess. In later versions of the library, the
solve() method was not template, and the function object to be passed
had to inherit from a base class. When we changed solve(), we didn't
bother changing the client code since it worked as it was.

Moreover, the inner class is not so bad. It encapsulates nicely a few
accessory object which otherwise should be kept as data members of the
CapFloor class itself. What we could do, however, is to avoid defining
it as an inner class. We could remove it from the header altogether and
define it in an anonymous namespace in the .cpp file. Did you spot any
other such class in the library?

Later,
	Luigi


---------------------------------------- 

I've finally learned what `upward compatible' means. It means we 
get to keep all our old mistakes. 
-- Dennie van Tassel