Why doesn't there exist a QuantLib Leg Hierachy?

Posted by Sebastian Poloczek on Nov 16, 2012; 5:27pm
URL: http://quantlib.414.s1.nabble.com/Why-doesn-t-there-exist-a-QuantLib-Leg-Hierachy-tp9632.html

Hello,

I've tried to "reconstruct" a QuantLib swap object in another environment (QuantLib Excel). The idea was to use the swap properties (including private ones if necessary) to construct adequate ObjectHandler::ValueObjects, which can be used to "design" the objects in an excel workbook.  

After some coding I've recognized that this seems to be impossible (or at least harder than expected) in the current QuantLib environment. The reason is that there is no QuantLib Leg Hierachy in the library. Each Leg is just a vector of cashflow pointers and it is hard to differentiate if a leg was intended to be an iborleg, a fixedrateleg etc.
For example you use the "helper class" fixedrateleg to (temporarely) create a fixedrateleg. As soon, as you pass it to a swap this fixedrateleg is just casted to a vector of cashflowpointers, loosing the information what it was intended to be. I'm wondering why this "design" was choosen.
I suppose that a structure similar to that:

typedef std::vector<boost::shared_ptr<CashFlow> > Leg;

// concrete FixedRateLeg class
class FixedRateLeg : public Leg {
....
}

//! helper class building a FixedRateLeg
class MakeFixedRateLeg {
        // similar to current FixedRateLeg helper class
        // cast operator on new FixedRateLeg Class instead of Leg:
        // operator FixedRateLeg() const;
}

would be in some circumstances superior to the current structure. This is (for example) the way the swap class (with its child vanillaswap) is organized. Is there a special reason that this "thing" Leg did not get an objecthierachy in QuantLib?

Regards
Sebastian