[petsc-dev] questions on new include organization

Matthew Knepley knepley at gmail.com
Wed Feb 13 21:22:44 CST 2013


On Wed, Feb 13, 2013 at 10: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.
>

This is also the result of DM doing too many jobs.


>
>> **  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130213/aec9cc53/attachment.html>


More information about the petsc-dev mailing list