<div dir="ltr"><div class="gmail_extra">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 class="im"><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>Are you talking hypothetically? Because what's in there now is just dispatch based on the types of PetscObjects.<br>
<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>