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
