<br><br><div class="gmail_quote">On Tue, Jan 15, 2013 at 2:55 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><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="im">On Tue, Jan 15, 2013 at 2:51 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br>

<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>I think passing PetscObject is natural here, in which case using obj->type_id instead of obj->type_name can be done later. But on that front, yes, I think making integers for all registered type_names would be good. Among other things, it would make the PetscObjectTypeCompares fast, although I think those places should eventually be refactored.</div>




</div></div></div></blockquote></div><div>Some of the arguments aren't PetscObjects (e.g., PODs).</div><div>Each dispatcher (e.g., MatMultMult) can have static integer typeids for all of its arguments that are registered</div>




<div>or retrieved only on the first invocation and reused from then on.</div></blockquote></div><br></div>Are you talking hypothetically? Because what's in there now is just dispatch based on the types of PetscObjects.<br>

</div></div></blockquote><div>Right.  I guess the non-PetscObject arguments don't vary between implementations, so we can stick to PetscObjects.   </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">
<br>Note that generic PetscObject routines would have to ensure that type ids never collided, even if the objects were of different classes. If we pass the object, that's easy to verify. The current PetscOpFListFind() will fail at distinguishing an AOBASIC from a SNESLINESEARCHBASIC or a PETSCSFBASIC. Passing PetscObject is safer in this regard.</div>


</div>
</blockquote></div>Right.  Typeids would have to be assigned to (classid,type_name) pairs, since type_names are only unique within a class. I'm on board with passing PetscObjects for argument matching (and squeezing out the non-PetscObject args).<div>

<br><div>There is, by the way, the 'type' field in the header, which the docs say should no longer be used, and which is typically set to 0 or -1 in calls to PetscHeaderCreate.  So, barring some subtle backward-compatibility issue this can be reused to hold the typeid, which is computed or looked up on each PetscObjectChangeTypeName()?</div>

</div><div><br></div><div>Dmitry.</div><div><br></div><div><br></div><br clear="all"><div><br></div>