Thanks. I now understand why they must be handled differently

On Jan 20, 2026, at 7:47 PM, Jed Brown <[email protected]> wrote:

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