[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