Problems? Is your data what you think it is? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Thanks! It didn't occur to me to search for "sub reference" as a synonym for "coderef" or "code reference"!
It will take me some time to go through the various suggestions and links, but from a brief scan, most of the suggestions, bar one, seem to rely on one or more B:: modules. I am looking for a solution that could be used on non-development machines, so those don't really apply. There is one, however, that looks very interesting: Devel::Peek. What I'm not clear on though is how that relates to ordinary Perl data types. The documentation seems to be written with XS developers in mind (of which I am not one). I would be grateful for a simple demo of how that module might be used within a MODIFY_CODE_ATTRIBUTES function to decorate a Perl (not XS) subroutine, e.g. with logging code before and after the original subroutine code. MODIFY_CODE_ATTRIBUTES only gets the code reference to which the attribute is attached, not the name. Without the name, there is no way to use the attribute to "decorate" foo(...) with before and after code, and then assign the decorated subroutine back to foo(...), like this:
Yes, yes, I know this can be done without attributes. There are loads of CPAN function decorator modules, but I'd like to know if it can be done using the current attribute interface. The most commonly recommended method for doing this, Attribute::Handlers, does not play nicely with the FETCH and MODIFY functions of the currently supported interface (nor should it - it was written in 2001). The issue is discussed in some detail here. My feeling is that the decoration implementation would be a lot cleaner if we had an attribute handler module that used FETCH and MODIFY. But to do that, I need a way to get from the coderef back to the original name of the function so I can reassign a new subroutine to the symbol table. And yes, yes, I know that the attribute interface is still experimental and even if we can find something now it may not work in the next release. Still, I'd like to know. Best, beth Update: Just took a look at Devel::Peek. I don't know that this will help - it appears that the package's MODIFY_CODE_ATTRIBUTES function is called before the association between the original name and coderef is set up. Here's the output when Devel::Peek::Dump is called from within a MODIFY_CODE_ATTRIBUTES method:
The GVGV::GV value is supposed to be the name of the subroutine (see here), but in this case it is set to 0x0. In reply to Re^2: Is there a way to access the name under which a subroutine was first defined?
by ELISHEVA
|
|