<p dir="ltr">Inheritance, like PCGAMG to PCMG. One more reason not to use inheritance.</p>
<div class="gmail_quote">On Dec 6, 2012 9:34 AM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Dec 6, 2012, at 10:27 AM, Jed Brown <<a href="mailto:jedbrown@mcs.anl.gov">jedbrown@mcs.anl.gov</a>> wrote:<br>
<br>
> On Wed, Dec 5, 2012 at 6:03 AM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>  I think you mean that DMDASNESSetFunctionLocal() sets a function pointer specific to DMSNES_DA (I don't think you mean to talk about plain "DM" here (yes I use the wrong object for a fortran function pointer recently but that was because I was lazy).<br>

><br>
>     Anyways, the cure is that each PetscObject has two fortran pointer arrays; the current one that handles the methods for the base class of the PetscObject (for example DMSNESSetFunction()) and the other specific for the subclass (for example DMDASNESSetFunctionLocal()). When a subclass gets changed with XXXSetType() the second fortran pointer array is deleted so you don't get "left over" wrong function pointers. Each subclass manages its own enums for the subclass so the base class fortran stuff doesn't need to know about the subclasses.<br>

><br>
>    Does that work?<br>
><br>
> What about derived classes? Must we have the subtype create set the number of required Fortran pointers?<br>
<br>
   Correct. The subtype manages its own set of pointers (and size) in its interface functions in the same way as we currently manage them for the base class. (With enums of course instead of raw numbers). The only thing that needs to be exposed outside of the fortran interface files is the freeing of the subclass pointer when the type changes.<br>

<br>
   Barry<br>
<br>
<br>
</blockquote></div>