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

[Luigi Ballabio]

On Mon, 2007-04-23 at 08:47 -0700, [hidden email] wrote:
> Revision: 10348
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10348&view=rev
> Author:   nando
> Date:     2007-04-23 08:47:20 -0700 (Mon, 23 Apr 2007)
>
> Log Message:
> -----------
> - adopted lower case filters in VC8 project
> - in folder marketmodels: moved all derived classes in their proper sub-folder

Hi,
        are we really going to have a marketmodels subfolder for each class
hierarchy? Of course I'm not against structuring the source tree, but
hierarchies are just an implementation detail (the clearest example of
this being the nodedataproviders folder.) I'd rather structure it
according to the domain; 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.

Later,
        Luigi


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

standards, n.:
The principles we use to reject other people's code.



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

On 4/24/07, Luigi Ballabio <[hidden email]> wrote:
>         are we really going to have a marketmodels subfolder for each class
> hierarchy? Of course I'm not against structuring the source tree, but
> hierarchies are just an implementation detail (the clearest example of
> this being the nodedataproviders folder.) I'd rather structure it
> according to the domain; 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

Anyway the main goal was just to clean up the top level marketmodels
folder: I wanted to clean up the former status where files had
obsolete names, including classes with different names, etc. The
former situation was quite hard to navigate even for me who's been
developing this material since day 1.

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Tue, 2007-04-24 at 10:06 +0200, Ferdinando Ametrano wrote:

> On 4/24/07, Luigi Ballabio <[hidden email]> 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



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev