QuoteOriginally posted by: renormAll that makes perfect sense. But Observer is a foundation of almost every class in QuantLib. Decoupling things from it is not possibleQuotewithout total rewriteIt is not about Observer alternatives, it is all about not breaking the legacy code. Observer interface is used in hundreds of source files.Around 1993 I worked in what was probably the first risk C++ system from a s/w vendor. The Observer pattern took centre stage. The two base class were derived from a Watchable object and its Observer. Then the class hierarchy went down the rabbit hole as it were to prodce a 6-deep hierarchy. Almost impossible to maintain, let alone document.So, what's the real problem with Observer? Well, OO Observer defines 2 classes Observable and Observer to model roles. Now roles are objects and dynamic while classese are static. So we model objects as classes.. Soon it breaks up.With Observer an object can only play one of the roles (unless you start messing with multiple inheritance which is the forbidden quarter). Just because (almost) everyone uses it does not mean it's correct. Microsoft stopped using it and now use Delegates. Boost Signals is a breath of fresh air.My solution wth Observer is @outrun's Husqvarna pruning suggestion

QuantLib uses multiple and virtual inheritance. Pruning Observer would be a good thing. But who is going to do it?

Would it not be an idea to provide a front-end to QL for users?Something likeOnline calculator You could offer it as a web service or a VS .msi setup file etc. Whatever.

QuoteOriginally posted by: outrunI've thought about various aspects quit a lot:* redesign* documentation, examples* simple call interface...but I can make no business-case, .. like so many interesting projects that eventually fail to get of the ground...What's the personal gain for such an effort?For how many people are we doing this?Who are those uses (developers, lib-users)?Are they happy with this?A business case is the learning curve; how long does it take to learn any product?Cost: (hourly_rate * Number of hours) + lost time that you could have been spending on production work.Someone on Wilmott was actually prepared to pay for support. Why? just look at the above cost equation.Why do developers tend not document their work?

There're really too much OO design and the code is over-engineered. To me, it is more or less an open source project that a group of dedicated developers try to show off their OO skills in quantitative finance. It'd be nice if the developers set up a wiki so that we all can contribute documentation to whatever part of the system we are familiar with. Look at wikipedia!

You mean like the wiki link in the sidebar on the QuantLib site?

outrun,I see your point. It is all about marginal benefit. In general, the marginal return (per time spent) from contributing to mature projects is less compared to working on fresh ideas, unless the said project is something big and famous.I tried to marry QuantLib with multithreading sometime ago. Facing too much rewrite and redesign I had to give up. I figured that it is easier to do it from the scratch and use QuantLib for sanity check.

Found this

Small rant. It relates to all applications that use Observer to its limits.I have been against Observer since 1994; In general it is a very 'bad' design (it is basically wrong but never mind). Many, many legacy applications use it...The 2010 solution is to use Signals and Signals2 libraries. You can use them as is and as building blocks for event-notification framework. It seems that Signals originated in Qt. So, use Observer in new projects at your peril. Sooner or later it will strangle your code. //The anecdote (true?) is that Microsoft exited the Java project because Java used the OO Observer. Then MS use Delegates, which is like a simpler version of Signals.

One way that we found to be useful to discover class hierarchies and the seeds of UML diagrams is to do a code review of some library (e.g. QL cubicinterpolator for bootstrapping/interpolating fwd rates) and search for:1. if else code (lots..)2. switch statements3. enumThen these are the seeds for a UML framework. New algos (e.g. HaganWest) is then a simple question of deriving classes and implementing specific virtual functions. There will be multiple interacting classes based on a data flow analysis. It's very easy but you need 1) to understand the algos 2) get the program working for one specific set of derived classes in the UML hierarchy (it is a (inductive) generalisation process, some people call it pattern mining). In general, even the code looks neater after such a review. You are programming and testing while at the same time making the code more flexible. And UML is a roadmap to keep you from rambling into wormhole code.

For developers with writer's cramp IEEE 1063-2001 might give a leg-up (to use a term from the horsey world). othersIEEE 1016-1998IEEE 1219-1998

One modest suggestion in the absence of the written word is to document libraries by screen and audio capture; you can then in 15-30 minutes explain all you need to know with minimum effort, for example using this approach

QuoteOriginally posted by: CuchulainnOne modest suggestion in the absence of the written word is to document libraries by screen and audio capture; you can then in 15-30 minutes explain all you need to know with minimum effort, for example using this approachThis taken to its logical conclusion by Verity Stob...http://collaboration.cmc.ec.gc.ca/scien ... /0305m.htm