[petsc-dev] Interesting

[Barry Smith]

On Mar 15, 2010, at 2:46 PM, Jed Brown wrote:

> 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.)

     One could simply add to PetscObjectQueryFunction() if the query  
object fails then do a query with the name key on the fallback table  
indexed by the class id integer. This will not break anything. Then  
overtime we could move many of the current "fallback"  
PetscObjectComposeFunction() calls in the XXXCreate_YYY() routines to  
initialize the fallback table in the PACKAGEInitialize() routinues.

    I like this idea so much lets implement right after the release.


    Barry

>
> 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