Some callbacks are meant to persist beyond an XSetType() while others must be
cleared when that is done. See the last line here.
PetscErrorCode PetscObjectChangeTypeName(PetscObject obj, const char
type_name[])
{
PetscFunctionBegin;
PetscValidHeader(obj, 1);
PetscCall(PetscFree(obj->type_name));
PetscCall(PetscStrallocpy(type_name, &obj->type_name));
/* Clear all the old subtype callbacks so they can't accidentally be called
(shouldn't happen anyway) */
PetscCall(PetscArrayzero(obj->fortrancallback[PETSC_FORTRAN_CALLBACK_SUBTYPE],
obj->num_fortrancallback[PETSC_FORTRAN_CALLBACK_SUBTYPE]));
PetscFunctionReturn(PETSC_SUCCESS);
}
The implementation would be more complicated if they went in the same list
because you'd have to distinguish class-scope reserved slots from subtype-scope
free slots.
Barry Smith <[email protected]> writes:
> Jed,
>
> How come you introduced this construct?
>
> typedef enum {
> PETSC_FORTRAN_CALLBACK_CLASS,
> PETSC_FORTRAN_CALLBACK_SUBTYPE,
> PETSC_FORTRAN_CALLBACK_MAXTYPE
> } PetscFortranCallbackType;
>
> That is why are there two types of callbacks, they seem to be managed the
> same way but go into two different lists in the object. I don't see why there
> cannot just be one list they all go in?
>
> Thanks
>
> Barry
