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
