Re: [Quantlib-dev] a simple question

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

Bonjour Fran=E7ois,
	sorry for the delay. Here we go:

On May 18, 2007, at 5:41 PM, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD=20
PHI wrote:
>> In this case, isValid_ should be protected and derived classes would=20=

>> have to manage it.
>
> I agree with you, we could also leave it as it is and provide a=20
> protected function setQuote() which would set isValid_ to true.
>
>> Using optional wouldn't be so tricky: we could just write SimpleQuote=20=

>> as >(without namespace boost)
>
> I agree again, provided that you add a resetQuote() method to your=20
> class, then the use of optional would be transparent to the user.

resetQuote() might not be necessary, as we can declare setQuote as=20
setQuote(optional<Real>). With this declaration,

q.setQuote(42);

would automatically package the Real in the optional, while

q.setQuote(none);

would make q a null quote.


>  Still, I have two remaining arguments:
> ->You have to reimplement this machinery in every quote classe.
> ->What would be the added benefit compare to a more traditionnal=20
> solution ? (like mine)
>
> I know that you will destroy these arguments in a couple of seconds,=20=

> but it is instructive to understand one's error anyway

Well, it's not an error. I just think it's a less than optimal solution=20=

:)
As for your arguments:

1) your solution actually leads to more machinery. Among the quotes we=20=

currently have, only SimpleQuote manages the value directly, so to=20
speak. For the other quotes, isValid() is implemented, for instance,=20
like this:

     bool ImpliedStdDevQuote::isValid() const {
         return !price_.empty()    && !forward_.empty() &&
                 price_->isValid() &&  forward_->isValid();
     }

In your approach, the above becomes:

     bool ImpliedStdDevQuote::isValid() const {
         isValid_ =3D !price_.empty()    && !forward_.empty() &&
                 price_->isValid() &&  forward_->isValid();
         return isValid_;
     }

i.e., management of the isValid_ data member (directly or via some=20
method) is forced upon the programmer, which can no longer implement=20
the interface by just writing the logic (as he does now) but instead=20
has to worry about the particular implementation of the base class. (*)

2) The added benefit comes from the above. No, let me rephrase this:=20
the added benefit is the fact that in the current approach, Quote is a=20=

pure interface; the above is a consequence. In your approach, you're=20
making Quote a somewhat less abstract base class, which is seldom a=20
benefit. Moreover, you're modeling it after SimpleQuote, which is just=20=

a particular case.

Later,
	Luigi

(*) This is the same issue I had with storing a dayCounter_ data member=20=

in TermStructure itself. On the one hand, we saved having to declare it=20=

in quite a few derived classes, but on the other hand we're left with=20
classes such as ImpliedTermStructure, which leaves it uninitialized.