[petsc-dev] questions on new include organization

[Barry Smith]

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).