VecLoadIntoVector and double dispatch

[Jed Brown]

I'm sort of confused about vec->ops->loadintovectornative, this seems to
just be a way to let users provide *one* custom viewer on a particular
vector without breaking PETSc's own viewers.  But it really doesn't
provide a reasonably solution for an intermediate library, or user code
with multiple viewers.

Extensible double dispatch is not something C is heralded for, but it's
not impossible.  An easy-to-code approach is to just do it all with
PetscObjectFunctionComposeDynamic.  The FList could get a bit long, but
I think you'd be hard-pressed to find a real code where dispatch time
for VecLoadIntoVector and (a couple of other viewer-related functions)
was an issue.  For best performance, PetscObject could acquire a field
for "type index" or some such (e.g. managed by
PetscObjectChangeTypeName), which would allow double-dispatch based on
table lookup.  (There are lots of variants of this idea, many C++
proposals force the linker to set up the table which is totally broken
with dynamic loading.)

Visitor isn't great as an extensible solution due to asymmetry and the
need to change the vtable of the other object.

A simple approach that is probably sufficient for VecLoadIntoVector
would be to move the pointer into viewer->ops because the viewer
typically just needs VecGetArray, and there is much more demand for new
viewer types than for new vector types.

Thoughts?

Jed