On Wed, Feb 13, 2013 at 8:06 AM, Barry Smith <bsmith@mcs.anl.gov> wrote:

You misunderstand me. I am not advocating replacing the more efficient access code using offset plus length to ALWAYS calling ISGetIndices() and using the indices to do the access. I absolutely am not advocating that. Recall we sometimes have subclasses that do not implement (or get used) all the methods of the base class.

What I am advocating is recognizing that PetscSection and IS have (in the abstract) very similar jobs and thus organizing the source code (naming, possible methods etc) to reflect this. Rather than having seemingly two completely unrelated classes.

For example, and I'm not advocating this naming, we could have a base abstract class of PetscIndex with PetscIndexIS and PetscIndexSection, now people always see the connection. The weakness of this exact approach is though both things are related to indexing, it is not clear they have any common methods (as you both have pointed out) so "deriving" them both from PetscIndex might not be best.

Hmm, PetscSection is strictly more general, so it would be possible for IS to be an implementation of PetscSection. Since these things are (at least after setup) immutable, the hierarchy doesn't come crashing down. The problem is that

1. With the way we do inheritance, you wouldn't be able to statically determine at the call site whether you had a general Section or the more restrictive IS. This affects ability to reason about the code locally, and in _most_ locations, we really need an IS.

2. PetscSection (at least) is performance-critical due to fine-grained accessors, so dynamic dispatch is a problem. If we had PetscSections of homogenous type, we could relieve it with multi-accessors, but that would be a weird interface by PETSc standards.