Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Re^3: Is there a way to access the name under which a subroutine was first defined?

by shmem (Chancellor)
on Feb 16, 2009 at 10:56 UTC ( [id://744033]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Is there a way to access the name under which a subroutine was first defined?
in thread Is there a way to access the name under which a subroutine was first defined?

It definitely does seems to be a compilation stage issue. My new toy Devel::Peek::Dump(...) also reports the subroutine name correctly if it is called after the sub is compiled, but not when the subroutine's attributes are being processed via MODIFY_CODE_ATTRIBUTES.

That's not a phase issue. Keep in mind that MODIFY_CODE_ATTRIBUTES actually wraps the subroutine into another one, by saving the reference from the typeglob and assigning the reference of the new (outer) subroutine to it: the subroutine reference *foo{CODE} is necessarily changed. Update: well, the contents of that. But the address in the typeglob remains the same, it seems... hmm.

Replies are listed 'Best First'.
Re^4: Is there a way to access the name under which a subroutine was first defined?
by ELISHEVA (Prior) on Feb 16, 2009 at 11:13 UTC

    Forgive me for being slow on the uptake, but if that is so, then why does the dump output (cited in my note) print the exact same reference address from both within MODIFY_CODE_ATTRIBUTES and after compilation? Are you saying that both are the wrapped original function? Why the wrapping?

    Also, I checked the dump output for GVGV::GV of a compiled anonymous function, and that isn't 0x00, but rather displays a name, something like "main" :: "__ANON__". If a wrapper were being passed as the code reference parameter to MODIFY_CODE_ATTRIBUTES, why isn't it printing out its anonymous name when we run it through Devel::Peek::Dump(...)?

    Best, beth

    Update: added observation about Devel::Peek::Dump(...) output for anonymous wrappers.

      Erm ... I meant MODIFY_CODE_ATTRIBUTES from Attribute::Handlers. Your MODIFY_CODE_ATTRIBUTES doesn't actually modify code attributes... Consider:

      #!/usr/bin/perl use strict; use warnings; use Devel::Peek(); BEGIN { sub bar; print STDERR "\nDumping " . \&bar . " in BEGIN.\n"; Devel::Peek::Dump(\&bar); } use Attribute::Handlers; use attributes; sub Lion : ATTR { print "\ngroaarr!\n"; } sub bar : Lion method { print "pling.\n"; } print STDERR "\nDumping " . \&bar . " after attr assignment.\n"; Devel::Peek::Dump(\&bar);

      Output:

      Dumping CODE(0x97ad654) in BEGIN. SV = RV(0x97c32c0) at 0x97a3c40 REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x97ad654 SV = PVCV(0x97aff40) at 0x97ad654 REFCNT = 2 FLAGS = () IV = 0 NV = 0 COMP_STASH = 0x976fb50 "main" ROOT = 0x0 XSUB = 0x0 XSUBANY = 0 GVGV::GV = 0x97b92ec "main" :: "bar" FILE = "attr2.pl" DEPTH = 0 FLAGS = 0x0 OUTSIDE_SEQ = 205 PADLIST = 0x97b92d4 PADNAME = 0x97936f0(0x0) PAD = 0x979366c(0x97781b0) OUTSIDE = 0x9770774 (UNIQUE) groaarr! Dumping CODE(0x97ad654) after attr assignment. SV = RV(0x97c3304) at 0x976fc28 REFCNT = 1 FLAGS = (TEMP,ROK) RV = 0x97ad654 SV = PVCV(0x97aff40) at 0x97ad654 REFCNT = 2 FLAGS = (METHOD) IV = 0 NV = 0 COMP_STASH = 0x976fb50 "main" START = 0x97adc90 ===> 4079 ROOT = 0x97ac540 XSUB = 0x0 XSUBANY = 0 GVGV::GV = 0x97b92ec "main" :: "bar" FILE = "attr2.pl" DEPTH = 0 FLAGS = 0x40 OUTSIDE_SEQ = 333 PADLIST = 0x97df7e0 PADNAME = 0x97bffbc(0x9777fc0) PAD = 0x97df798(0x97e1150) OUTSIDE = 0x976fdf0 (MAIN)

      Note the changed PVCV.

        Now...that makes a *lot* more sense :-)

        But, actually, I was trying to come up with a way of defining MODIFY_CODE_ATTRIBUTES that didn't require all the conniptions that Attribute::Handler is going through. To create those wrappers and assign them to the symbol table Attribute::Handler defines a MODIFY_CODE_ATTRIBUTE method that generates a bunch of handlers that run at various compilation phases, some of which don't play well with mod_perl (as noted by Thilosophy). It also stores the coderefs it gets from parameters passed to MODIFY_CODE_ATTRIBUTES in a hash for later pairing up with names (see its _gen_handler_AH_(...) and findsym(...) functions).

        It is pretty obvious now why Attribute::Handlers does all this: the implementers of the attribute facility left a construction site half built as Thilosophy so eloquently put it. Time? Release dates? Inability to come up with a robust consistent design? Who knows? The perldocs hint at the last issue, but one would have to search the developer archives to know for sure. In any case, we are left with various workarounds.

        Thank you so much for taking the time to help me better understand this.

        Best, beth

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://744033]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (5)
As of 2024-03-28 22:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found