VecLoadIntoVector and double dispatch
jed at 59A2.org
Sat Dec 5 10:55:47 CST 2009
On Fri, 4 Dec 2009 18:29:19 -0600, Barry Smith <bsmith at mcs.anl.gov> wrote:
> This may be crux of the current discussion.
This part was actually orthogonal to the extensible double dispatch
issue which was:
It should be possible for VecView(X,V) to invoke a third-party viewer
V even when X (including the DM associated with it) has never come in
contact with code that is aware of the implementation of V.
So there is no opportunity to modify vec->ops. I'm thinking of
dynamically loading PetscViewerCreate_Foo, and selecting it with
-viewer_type foo. Every other PETSc object has this ability,
dynamically loaded implementations are first-class, they certainly don't
require modifying other objects to be functional. But they only need
single-dispatch, extensible double dispatch is hard and every solution
involves compomises. I'm just frustrated with the current compromise,
maybe it would be better if the language made the choice for us by
offering native multimethods.
Dispatch through the DM has no effect on this problem, it only avoids
having a Vec with the same type name, but different type (because it has
different methods) and "viewnative" being a special case, and it's not a
big deal to me.
More information about the petsc-dev