[petsc-dev] questions on new include organization

[Barry Smith]

On Feb 13, 2013, at 9:22 PM, Matthew Knepley <knepley at gmail.com> wrote:

> 
> My justification for splitting out the DM implementation headers was that KSP/SNES/TS depend on the DM interface, but should not (there may be a couple places that cheat) depend on the DMDA/DMPlex/etc interfaces. I would say that any include of petscdmxxx.h outside of dmxxxsnes.c is a bad dependency. The user, on the other hand, always depends on the implementation, so they should include petscdmxxx.h.
> 
> This is also the result of DM doing too many jobs.

  Not at all. It has two jobs: talking to the mesh data and talking to the solver objects. What makes it seem to have many jobs is that each type of mesh object has its own language.

>  
> 
> **  Note we don't do this for sub sub classes, KSPLGMRES should be KSPGMRESL etc. pity we should have done it right.
> 
> I see the appeal of hierarchies, but I find them rigid and inconvenient. I definitely prefer object models (interface and implementation, but no implementation inheritance). The only reason for implementation inheritance is code sharing, but I think that's frequently a false economy and comes back to bite us in brittleness. If we had a lightweight way to selectively forward methods, we could break out the sharable part into an internal object with well-defined methods and avoid the piggy-back overriding of methods (implementation inheritance).
> 
> I agree with this. I have never seen inheritance buy anything in the real world.
> 
>    Matt
> 
> -- 
> What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.
> -- Norbert Wiener