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