in reply to Re: 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?

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:

use strict;
use warnings;
use Devel::Peek();

sub MODIFY_CODE_ATTRIBUTES {
  my $sPackage = shift @_;
  my $crSub = shift @_;
  print STDERR "Dumping $crSub in MODIFY_CODE_ATTRIBUTES:\n";
  Devel::Peek::Dump($crSub);
  return ();
}

BEGIN {
  sub bar : Lion {
    print "pling.\n";
  }
  print STDERR "\nDumping " . \&bar . " after compilation.\n";
  Devel::Peek::Dump(\&bar);
}

[download]

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:

Dumping CODE(0x818a994) in MODIFY_CODE_ATTRIBUTES:
SV = RV(0x819e958) at 0x8197600
  REFCNT = 1
  FLAGS = (PADBUSY,PADMY,ROK)
  RV = 0x818a994
  SV = PVCV(0x818ddb8) at 0x818a994
    REFCNT = 5
    FLAGS = ()
    IV = 0
    NV = 0
    COMP_STASH = 0x0
    ROOT = 0x0
    XSUB = 0x0
    XSUBANY = 0
    GVGV::GV = 0x0
    FILE = "(null)"
    DEPTH = 0
    FLAGS = 0x0
    OUTSIDE_SEQ = 208
    PADLIST = 0x818a97c
    PADNAME = 0x8184450(0x0) PAD = 0x818aa00(0x81a5830)
    OUTSIDE = 0x8183288 (UNIQUE)

Dumping CODE(0x818a994) after compilation.
SV = RV(0x819e940) at 0x819bb48
  REFCNT = 1
  FLAGS = (TEMP,ROK)
  RV = 0x818a994
  SV = PVCV(0x818ddb8) at 0x818a994
    REFCNT = 2
    FLAGS = ()
    IV = 0
    NV = 0
    COMP_STASH = 0x814eb50    "main"
    START = 0x816e678 ===> 2993
    ROOT = 0x81afbc0
    XSUB = 0x0
    XSUBANY = 0
    GVGV::GV = 0x818ab44    "main" :: "bar"
    FILE = "Monks/Snippet.pm"
    DEPTH = 0
    FLAGS = 0x0
    OUTSIDE_SEQ = 208
    PADLIST = 0x818a97c
    PADNAME = 0x8184450(0x819caf8) PAD = 0x818aa00(0x81a5830)
    OUTSIDE = 0x8183288 (UNIQUE)

[download]

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

Replies are listed 'Best First'.
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
    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]

        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);

        [download]

        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)

        [download]

        Note the changed PVCV.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom