RE: Swap Ratehelper

Posted by Luigi Ballabio-4 on Apr 30, 2002; 11:34am
URL: http://quantlib.414.s1.nabble.com/Swap-Ratehelper-tp10071p10072.html

At 03:54 PM 4/30/02 +0200, Andre Louw wrote:
>Luigi,
> > I don't have a strong feeling against adding units to the present
> > constructor, either. It's not that big an inconvenience
>
>Except for everybody using it currently?

This is true. However, it is also true that a) I'd like to think that at
release 0.3.0 we are still free to change our minds if we see a drawback in
our earlier choices, and b) last week we changed the TermStructure
interface and the PiecewiseFlatForward constructor; users already have to
change their scripts, and this change might be just another epsilon. Then
again, I'm not suggesting this as the standard process.

>I suppose you can add the units to the end of the parm-list with an
>initialised value of 'Years', but that's not very neat, I would prefer to
>have it next to the number-of-units?
>What's the QuantLib dev community's general rule-of-thumb, I'm used to
>adding a new constructor (minimising the influence on existing codes)?

As for me, no rule-of-thumb valid for all cases. There are times when
multiple constructors give me the feeling that a class is trying to do too
much and should be refactored. However, this is not the case since it is
just a matter of default arguments; I would add a new constructor with the
parameters in the right order and maybe deprecate the old one in order to
remove it in the next release. The latter would depend on this release
being 0.3.0: were it closer to 1.0, I'd leave the old constructor alone.
Also, I would put the common initialization code in a private initialize()
method that both constructors would call, much like you did with the
CompoundForward constructors.

Anyway, mine is just one vote, and we are quite a few now.

Bye,
         Luigi