[petsc-dev] PETSC_FORTRAN_CALLBACK_CLASS vs PETSC_FORTRAN_CALLBACK_SUBTYPE ?

[Barry Smith]

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 <bsmith at petsc.dev> wrote:
> 
> Thanks. I now understand why they must be handled differently
> 
> 
>> On Jan 20, 2026, at 7:47 PM, Jed Brown <jed at jedbrown.org> 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 <bsmith at petsc.dev> 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
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20260120/7ea5926d/attachment.html>