Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10348] trunk/QuantLib

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

On Tue, 2007-04-24 at 10:06 +0200, Ferdinando Ametrano wrote:
> On 4/24/07, Luigi Ballabio <lui...@gm...> wrote:
> > for instance, the subfolders basissystems,
> > exercisestrategies, exercisevalues and nodedataproviders could as well
> > disappear and the files in them could be moved into a single folder
> > named callability.
> fine with me if you prefer this way, and I agree that in the current
> situation this might be better. Anyway my personal preference would be
> for sub-folder to reflect class hierarchies: imho this helps code
> browsing very much, especially since I forecast more BasisSystem and
> ExerciseStrategy classes being developed in the next months

It helps only if you know what class hierarchies are used (and how) for
a particular domain. In the current situation, a new user is more likely
to look into the marketmodels folder and say "nodedataproviders? What
are those for?" At which point he should hunt in other browsers (without
much help from the file structure) to find out to what other hierarchies
it is related and how it should be used.

On the other hand, if all files were in a callability folder (and
honestly, I don't have much of a problem with, say, 30 files in the same
folder as long as they're aptly named) it would be clear that the
corresponding hierarchies are related.

As for documenting class hierarchies for code navigation, that is easier
to do than documenting relationships between hierarchies. Exploring a
hierarchy is a mechanical process and can be done automatically (see <
http://quantlib.org/reference/class_quant_lib_1_1_market_model_evolver.html> for an example.) Your IDE does it too if you open its class browser.

Thoughts? Should I make the changes and branch?

Later,
	Luigi


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

Academic: a term of opprobrium applied to those that do their job well 
by those who cannot. 
-- Sir Ernest Gowers