[petsc-dev] PETSC_FORTRAN_CALLBACK_CLASS vs PETSC_FORTRAN_CALLBACK_SUBTYPE ?

[Barry Smith]

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