|No such thing as a small change|
Attributes are not for the faint of heart
Ain't that the truth! Thank you so much for the suggestion, but it didn't work within MODIFY_CODE_ATTRIBUTES. Sigh... Your "another major catch" seems to be right on. Your proposal exhibits the same behavior as Devel::Peek::Dump - works great after compilation (even in a BEGIN block) but not in MODIFY_CODE_ATTRIBUTES. The association between symbol and name does not appear to be set up until after the MODIFY_CODE_ATTRIBUTES function completes. This small script...
I am more than a little surprised that it is so difficult to use MODIFY_CODE_ATTRIBUTES to redefine functions. When I scanned the web last night in response to your query on attribute handling it seemed that one of the major use case for attributes is decorating functions. It seems a little strange to add a feature that can't be used for one of its major use cases.
Update: fixed some typos, added comment about blocks, some clarifications.
Further update: Just reread the Perl documentation for attributes and I think I finally understand what the last sentence of this quote might mean. Do you suppose "cloned copies ... used as closures" means decorated functions?... and the reason for this non-implementation being that the coderef is only partially set up? (i.e. not part yet of the symbol table)
WARNING: the mechanisms described here are still experimental. Do not rely on the current implementation. In particular, there is no provision for applying package attributes to 'cloned' copies of subroutines used as closures.
It does appear that the only way to get decorated functions is to set up CHECK handlers or do ugly things like store a hash keyed by code ref and then match up the names and the coderefs later on, a la Class::Declare.
In reply to Re^2: Is there a way to access the name under which a subroutine was first defined?