Comment 8 for bug 1209713

Let's suppose a developer is willing to extend JarrowRudd, for instance.
It may be necessary to add more arguments to a constructor or get rid of an unneeded argument. This scenario is not totally new; we already have this scenario happening at the moment: have a look at @Unused annotation and where it is used. I created this annotation to mark those arguments which appear in a method (or constructor) signature and which are not used inside that scope. It happens in some classes of BinomialTree hierarchy. What I mean to say is:

If we opt to [continue to] let the callee (BinomialVanillaEngine) decide how a BinomialTree is instantiated, the callee will have to make some assumptions and will have to have some 'insider' knowledge how a BinomialTree is instantiated. In this scenario, we have to write our extended class conforming to previous constructor signatures, probably keeping arguments we dont need and marking them as @Unused only for better documentation.

On the other hand, suppose that our extended class needs to add more arguments to constructors. Now we have a problem :( because there's no immediate way to integrate this new class to the existing ones without having to modify all constructor signatures of an entire hierarchy. This is where your suggestion is helpful, because we could solve this problem simply allowing and instance (besides .class) to be passed to BinomialVanillaEngine as argument.

What I said in the previous note I've written is that it's not needed at the moment because QuantLib does not provide it [at the moment] and I'm talking about the specific case of BinomialVanillaEngine. But I agree that it can be desirable anyway in order class hierarchies and eventually the one we are discussing now.

So, let's go ahead and suppose a very flexible thing:

1. We accept C++ style calls using the concept of Super Type Token in order to retrieve parametric generic arguments in calls like this:

// calling using Generics and using an anonymous class
PricingEngine engine = new BinomialVanillaEngine<JarrowRudd>(...) {};

2. We accept 'well behaved' Java style calls passing Classes as arguments:

PricingEngine engine = new BinomialVanillaEngine(JarrowRudd.class, ...);

3. We accept a user-suplied thing:

BinomialTree tree = new MyModifiedJarrodRudd(myCustomArg1,...,myCustomArgN);
PricingEngine engine = new BinomialVanillaEngine(tree, ...);

I dont see any problem on having 3 flavors for doing the same thing (or almost the same thing). The more flexibility the better.

What I said (and I insist!) is that BinomialVanillaEngine (in particular!) does not need case (3) *at the moment*.

IMHO, the library needs to be coherent.
So, I think we could eventually create an issue in Mantis intended to promote a complete code review, in the entire library, aiming to standardize how we provide such flexibility. For doing this, first we need to complete the translation of v0.8.1, in order to perform once and properly a code review which is complete.

I vote for opening an issue on this topic, providing the directions needed to be remembered at the time of implementation. Or maybe adding these directions to this issue.

Thanks. Very good discussion! :)

Richard