On Wed, Feb 13, 2013 at 2:14 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > * There are other petscxxx.h include files, but generally the user need > only include petscPACKAGENAME.h though Jed seems to have broken this model > with some subclasses like petscdmda.h petscpcmg.h etc not being included by > petscdm.h and petscpc.h (hmm this is both good and bad) not including a > bunch of stuff the user doesn't need or specifically request is good but on > the other hand the user has to specifically include it (increased learning > curve). So to use PCMG functionality directly one must include petscpcmg.h > directly but to use field split they don't need petscpcfieldsplit.h this > can lead to user exasperation (and mine)! >
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. > > ** 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). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130213/a2c9818d/attachment.html>
