<div dir="ltr">On Wed, Feb 13, 2013 at 10:16 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Wed, Feb 13, 2013 at 2:14 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>
*  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)!<br>

</div></blockquote><div><br></div></div><div>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.</div>
</div></div></div></blockquote><div><br></div><div style>This is also the result of DM doing too many jobs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
**  Note we don't do this for sub sub classes, KSPLGMRES should be KSPGMRESL etc. pity we should have done it right.</div></blockquote></div></div><br>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).</div>

</div>
</blockquote></div><br>I agree with this. I have never seen inheritance buy anything in the real world.</div><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<br clear="all"><div><br></div>-- <br>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>
-- Norbert Wiener
</div></div>