Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

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

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


in reply to Is there a way to access the name under which a subroutine was first defined?

Initially? The definitions don't carry a timestamp. It all depends on when you are doing your checks.

$\ = $/; sub foo; print "foo ref is: ",\&foo; my $ref = \&foo; for (keys %main::) { print "1: ",*{$_}{NAME} if *{$_}{CODE} and *{$_}{CODE} eq $ref; } *bar = *foo; sub foo { print "in foo" } for (keys %main::) { print "2: ",*{$_}{NAME} if *{$_}{CODE} and *{$_}{CODE} eq $ref; } bar(); __END__ foo ref is: CODE(0x91cf78c) 1: foo 2: bar 2: foo in foo
  • Comment on Re: Is there a way to access the name under which a subroutine was first defined?
  • Download Code

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

    By "initially" I meant the name "foo" assigned by sub foo {...} rather than any aliases assigned at a later point.

    But as you point out, it definitely does seems to be a "when" 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 (during the compilation of the subroutine definition).

    This is illustrated by the following small script:

    which reports GVGV:GV = 0x0 when called within the MODIFY_CODE_ATTRIBUTES method but GVGV::GV = 0x819ba28    "main" :: "bar" when called after bar(...) is compiled, as the captured output below shows:

    Best, beth

    Update: replaced original example with script illustrating different outputs from within MODIFY_CODE_ATTRIBUTES and after compilation; added explanation of what I meant by "initially".

      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.

        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.

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2024-04-20 08:29 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found