On Feb 13, 2013, at 9:16 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > 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. Understood and not completely unreasonable. Should we, should we not do the same thing for the other PCs? What about KSPs? Definitely no for KSPs. > > > ** 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. The KSP -> gmres -> l or F; I am talking about is from the user perspective (I agree that any implementation inheritance is secondary and certainly not important to the users). The question is do we give the user a list of 20 KSP or do we give them sets of related ones. I am arguing that presenting them as sets of related ones is better. > 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).
