[petsc-dev] -ksp_view_binary with DA vectors

[Jed Brown]

On Wed, 4 Aug 2010 10:17:16 -0500, Barry Smith <bsmith at mcs.anl.gov> wrote:
>   A DA MPI vector isa MPI Vec with a new VecView and a DA MPI Mat isa
>   MPI Mat with a new MatView() the simplest implementation inheritance
>   you can think of.

A reasonable invariant for vec might be tested by

  P1: VecSetValue(X,4,PETSC_PI,INSERT_VALUES);
      VecView(viewer,X);
      Check that the fourth entry is pi

If this is explicitly not guaranteed (e.g. the VecView interface
specifies that any permutation of entries is acceptable output), then
forwarding VecView() to a new DA ordering is fine.  But it seems
reasonable/natural/expected for P1 to hold, and breaking such an
invariant through inheritance is a very undesirable property (formalized
in http://en.wikipedia.org/wiki/Liskov_substitution_principle).

Now we could instead create

  P2: VecSetValue(X,4,PETSC_PI,INSERT_VALUES);
      PetscViewerSetFormat(X,PETSC_VIEWER_NATIVE);
      VecView(viewer,X);
      Check that the fourth entry is pi

Now P2 holds through inheritance, and Barbara can be happy.

>    In general I favor the idea of being able to dynamic add new
>    methods to objects; the specifics of instancemethod() I don't
>    know. In fact, I got the original idea of
>    PetscObjectComposeFunction() from the ability to do this in
>    Objective C.

Certain things benefit greatly from being dynamic.  But that comes at a
cost, namely type safety, static analysis, and performance (depending on
language), so I like to avoid it except where it offers a clear benefit.
Having a mutable vtable is very useful to hack in some weird behavior,
but it feels naughty as a standard way to implement APIs (and there are
lots of examples in the Ruby and Python communities of it turning into a
mess), so again, I try to limit the use to when there is no reasonable
alternative within the type system we have.

Jed