[fpc-devel] Consideration on "$CapturerClass" - reference to function - and debugging

Martin Frb lazarus at mfriebe.de
Tue Aug 25 09:21:02 CEST 2026


I understand that a reference to a function is an interface, and 
therefore the only really know think is that it has zero, one or more 
functions, and the definition of those functions...

In practice reference to function has an underlying Pascal class that 
implements the function. This class is of course hidden, and it could 
change, and no guarantees are given.

That does not mean, that it might not be useful if a debugger could show it.

FpDebug already can resolve interfaces to a class that implements it => 
if that class exists. => It is the user responsibility to trigger this 
on such data only (in practice errors will be detected...)

The syntax in a watch for fpdebug is:  i2o(the_interface)

And that works for "reference to function" too.
Well, if and only if you are paused in the very method that does the 
capture.

Because for some reason the class is declared inside the function. So 
its scoped to only exist there.

True another work around could be added to the debugger, and functions 
could be all searched.

*** But the question is: Could the compiler just write that class on the 
top level? ***

Yes, the name is not always unique. But that already exists for user 
defined classes too.
And the name is unique per compilation unit.
So there would be no problem arising from putting it at top level.


Not sure if the name could be made more unique?
- generic like hash
- or include (in addition to module,file,line,col) the type name of the 
declared ref=type: "TFoo = reference to function" (then it would be the 
users responsibility)


More information about the fpc-devel mailing list