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

[download]
  • 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:

    Read more... (629 Bytes)

    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:

    Read more... (1338 Bytes)

    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".

[reply]
[d/l]
[select]
      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.

[reply]

        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.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom