On Nov 26, 2010, at 12:32 PM, Jed Brown wrote:
> This seems to be equal to either 0 or -1 for every type in PETSc. The
> comments for PetscHeaderCreate suggest that it no longer has any meaning, but
> we still have PetscCheckSameTypeAndComm. What was the intent of this field?
Originally types were ints; that field has hung around ever since then. It
is not used and should be removed. Then replaced with something better.
> Is it to have a faster way than strcmp to check whether two implementations
> match?
Not currently. We have PetscClassId and class_name. We could also have
PetscTypeId and type_name in the PetscObject struct. When XXXRegisterDynamic()
is called it could create a new PetscTypeId for the string name. When an
XXXSetType() is called it could determine the Id based on the string name of
the type set in (how to do this efficiently, would it search through a list of
strings?) I think we should think about this a bit before doing it.
For example, I don't like the fact that PetscClassIDRegister() is in the
LOGGING stuff, since it is fundamental to PetscObject design and is not "only"
logging.
>
> I'm thinking about how to handle Vec operations of heterogeneous type which I
> don't think it is a short-term priority.
I have some ideas on this that would not involve comparing types. But still
needs lots of thought.
Barry
>
> Jed
