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