[petsc-dev] Interesting

[Jed Brown]

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