On Mon, 15 Mar 2010 14:15:51 -0500, Barry Smith <bsmith at mcs.anl.gov> wrote: > > Neat stuff. Thanks for pointing it out. > > I don't think we "need" something this general and powerful for > current PETSc; though if we were starting to write PETSc today?
Right, and I'm especially concerned about the debuggability. This is always a problem with metaprogramming, but especially so when there is no tool support. > The one place I'd really like to clean up is the double dispatch > of XXXXView() to get rid of the ugly if () dispatches. But I think > that is best done using the queryfunction() infrastructure we already > have, rather than a more general solution. Unless someone has some > simple, slick alternative. The trouble with queryfunction (at present) is that it is per-object, and thus only extensible if the extender can get their hands on the object. An alternative is to have a global dispatch object (can just be an FList, with a registration interface). If you want to retain per-object control over dispatch (acknowledging that this introduces asymmetry), then the global table can be just a fallback. (PetscObjectQueryFunction is implemented in terms of PetscFListFind, so I'm just suggesting a per-generic-function FList instead of per-object for XXXView.) If dispatch performance becomes an issue, then a small hash table can be used in front of the expensive string matching (this is what CLOS, COS, and most other multiple dispatch languages do). Jed
