[petsc-dev] questions on new include organization

[Jed Brown]

On Wed, Feb 13, 2013 at 8:06 AM, Barry Smith <bsmith at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130213/28e9df13/attachment.html>