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

[Luigi Ballabio]

On Thu, 2008-01-31 at 01:02 -0800, [hidden email] wrote:

> Revision: 14226
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=14226&view=rev
> Author:   nando
> Date:     2008-01-31 01:02:55 -0800 (Thu, 31 Jan 2008)
>
> Log Message:
> -----------
> renamed files
>
> Added Paths:
> -----------
>     trunk/QuantLib/ql/instruments/makeswaption.cpp
>     trunk/QuantLib/ql/instruments/makeswaption.hpp
>
> Removed Paths:
> -------------
>     trunk/QuantLib/ql/instruments/makeswaptions.cpp
>     trunk/QuantLib/ql/instruments/makeswaptions.hpp

How about putting MakeSwaption together with Swaption, instead? (And the
same for the other helpers, of course.)

Luigi


--

Anyone who says he can see through women is missing a lot.
-- Groucho Marx



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

On Thu, Jan 31, 2008 at 10:13 AM, Luigi Ballabio
<[hidden email]> wrote:
>  >     trunk/QuantLib/ql/instruments/makeswaption.cpp
>  >     trunk/QuantLib/ql/instruments/makeswaption.hpp
> [...]
>  How about putting MakeSwaption together with Swaption, instead? (And the
>  same for the other helpers, of course.)

oh boy! as it often happens, I was thinking in the exact opposite direction ;-)
I was considering to move the MakeSchedule code out of schedule.*pp
into its own files.

The rational for my preference is that we have huge nested
dependencies because of too-large too-often-included hpp files and
this triggers a lot of avoidable recompilations.
While some recompilation is now avoided thanks to the increasing usage
of forward declaration, I would favour breaking up hpp declaration
files in reasonably small units.

By the way, the _whole_ library is currently being recompiled as I
write just because I've added 2 inspectors to the Option class. This
happens just because the enum Type { Put, Call } is inside the Option
class definition instead of being outside (in its own file) and this
enumeration is of course used in a lot of places, even where the
Option class is not used at all :-(

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Thu, 2008-01-31 at 10:28 +0100, Ferdinando Ametrano wrote:
> >  How about putting MakeSwaption together with Swaption, instead? (And the
> >  same for the other helpers, of course.)
>
> oh boy! as it often happens, I was thinking in the exact opposite direction ;-)
> I was considering to move the MakeSchedule code out of schedule.*pp
> into its own files.

Nando,
        this won't buy you anything. On the one hand, makeschedule.hpp would
include schedule.hpp, so other files that include makeschedule.hpp would
bring in schedule.hpp anyway. On the other hand, makeschedule.hpp
wouldn't include anything more than what's already included in
schedule.hpp (because all arguments of the MakeSchedule methods are
arguments of the Schedule constructor) so you don't save any inclusion
by removing it from schedule.hpp.  QED.  The same applies to other
MakeFoo classes.


> By the way, the _whole_ library is currently being recompiled as I
> write just because I've added 2 inspectors to the Option class.

Sure. But you have to weight it---how often do you expect to change the
Option class, now that you've added the missing inspectors? Ok, you'll
have to recompile the _whole_ library every four months. On the other
hand, we get a more logical structure. Seems acceptable to me...

Later,
        Luigi


--

Glendower: I can call spirits from the vasty deep.
Hotspur: Why, so can I, or so can any man;
But will they come when you do call for them?
-- King Henry the Fourth Part I, Act III, Scene I



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

On Thu, Jan 31, 2008 at 10:57 AM, Luigi Ballabio
<[hidden email]> wrote:
>  makeschedule.hpp would
>  include schedule.hpp, so other files that include makeschedule.hpp would
>  bring in schedule.hpp anyway [...] so you don't save any inclusion
>  by removing it from schedule.hpp.  QED.  The same applies to other
>  MakeFoo classes.

yes, this was clear to me. Hope you have little doubts about it ;-)

My point is that any change to makefoo.hpp would not trigger
recompilation of files depending on foo.hpp
And it should be obvious that many more files/classes depends on
foo.hpp (main class) declarations than on the makefoo.hpp  (utility)
declarations.

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Thu, 2008-01-31 at 11:30 +0100, Ferdinando Ametrano wrote:
> My point is that any change to makefoo.hpp would not trigger
> recompilation of files depending on foo.hpp

Yes, but how many times are we going to change the interfaces again?

Luigi


--

The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" but "That's funny..."
-- Isaac Asimov



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

On Thu, Jan 31, 2008 at 11:51 AM, Luigi Ballabio
<[hidden email]> wrote:
>  Yes, but how many times are we going to change the interfaces again?
enough to care about, in my opinion. Of course your mileage might vary...

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Thu, 2008-01-31 at 11:59 +0100, Ferdinando Ametrano wrote:
> On Thu, Jan 31, 2008 at 11:51 AM, Luigi Ballabio
> <[hidden email]> wrote:
> >  Yes, but how many times are we going to change the interfaces again?
> enough to care about, in my opinion. Of course your mileage might vary...

Aren't we supposed to release a stable 1.0 this year? "Stable" as in
"client code should keep working with later releases without changes"?
Ok, we can postpone joining the headers until we're close to freeze.
But after that, I would value more grouping related classes to make
their relationship clear, or making immediately clear to a user looking
at schedule.hpp that a MakeSchedule class is available. After all, the
recompilation problem affects only a handful of users---you, me, and a
few others that work on the repository; most users just build the
released library once.

Luigi


--

A programming language is low-level when its programs require attention
to the irrelevant.
-- Alan Perlis



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando M. Ametrano-3]

On Thu, Jan 31, 2008 at 1:25 PM, Luigi Ballabio
<[hidden email]> wrote:
>  Aren't we supposed to release a stable 1.0 this year? "Stable" as in
>  "client code should keep working with later releases without changes"?
Yes we are. Anyway I miss the relationship between the stability the
library should guarantee from 1.0 onward and the way we organize our
header files.

>  I would value more grouping related classes to make
>  their relationship clear, or making immediately clear to a user looking
>  at schedule.hpp that a MakeSchedule class is available.
I hoped that documentation would have been in charge of that, while
header file organization would have served the developer community. I
might be wrong, but this was your argument when I tried to use folder
structure to surrogate some lack of documentation

>  After all, the
>  recompilation problem affects only a handful of users---you, me, and a
>  few others that work on the repository; most users just build the
>  released library once.
After all, I must confess I'm concerned much more about my needs than
"most (other) users" needs. Don't get me misunderstood, I am committed
to free software and open source 100% as I've always been from the
start of the QuantLib project. it's just that I spend my coding hours
for my employer and my personal interests, not to serve generic end
users.
Trust me: those end users are longing for documentation, and don't
mind about header organization.

Last but not least, I would love if somebody else would join this
thread and contribute his opinion. Otherwise my proposal would be to
continue just between you and I in front of a beer ;-)

ciao -- Nando

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Thu, 2008-01-31 at 16:14 +0100, Ferdinando Ametrano wrote:
> On Thu, Jan 31, 2008 at 1:25 PM, Luigi Ballabio
> >  I would value more grouping related classes to make
> >  their relationship clear, or making immediately clear to a user looking
> >  at schedule.hpp that a MakeSchedule class is available.
> I hoped that documentation would have been in charge of that, while
> header file organization would have served the developer community. I
> might be wrong, but this was your argument when I tried to use folder
> structure to surrogate some lack of documentation

What? You mean I'm not supposed to turn my own arguments top-down for
the sake of whatever side I'm currently taking? :)

Well, it seems like you caught me. I've no other choice than to
gentlemanly acknowledge defeat. You win.

Later,
        Luigi


--

The shortest way to do many things is to do only one thing at once.
-- Samuel Smiles



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev