https://urldefense.us/v3/__https://gitlab.com/petsc/petsc/-/merge_requests/8968__;!!G_uCfscf7eWS!dJFZ-qcE6UeiAUThtF-IPSflOzrbAeWRVxOck1wG5qyH9PmhwzWA7acip4EEakXDDW6PMoJ0P7gb7trWVaOZ6Q$
> On Jan 20, 2026, at 9:26 PM, Barry Smith <[email protected]> wrote: > > 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 >
