Index and Xibor

[Daniele De Francesco-2]

Hi all,

We are trying to create a Floating cashflow that resets off an index which
is not really a Xibor.
The problem is that the IndexedCoupon class that we use for our floating
cashflows takes a xibor as input and not a more generic index.
We would like to create our own strange subclass of Index, but we won't be
able to use IndexedCoupons if we do that.
We then thought that we could create our Index as a subclass of Xibor to get
around the problem. But unfortunately xibor doesn't have fixing() as a
virtual method.

Fortunately, QL being open source, we can just change the code to our
liking, but I'm wondering if there was some good reason that lead to the
current design choice for Index and its subclasses. As far as I can tell I
would have more of the Xibor's methods up in the Index interface and would
make Xibor's fixing() method virtual just in case.

I would be more than glad to provide a patch for evaluation if my idea seems
reasonable.

-Daniele

[Luigi Ballabio-2]

On 2004.09.10 19:55, Daniele De Francesco wrote:

> We are trying to create a Floating cashflow that resets off an index
> which is not really a Xibor.
> The problem is that the IndexedCoupon class that we use for our
> floating cashflows takes a xibor as input and not a more generic  
> index.
> We would like to create our own strange subclass of Index, but we
> won't be able to use IndexedCoupons if we do that.
> We then thought that we could create our Index as a subclass of Xibor
> to get around the problem. But unfortunately xibor doesn't have  
> fixing() as a virtual method.

Daniele,
        fixing() is declared virtual in class Index from which Xibor  
inherits, therefore Xibor::fixing() is virtual too--even if it's not  
explicitly declared as such.  However, you're right: IndexedCoupon  
should take an Index. Go ahead and send me the patch.

Later,
        Luigi