Re^2: 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".

Comment on Re^2: Is there a way to access the name under which a subroutine was first defined? Select or Download Code

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]
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.	[reply] [d/l] [select]
Re^5: Is there a way to access the name under which a subroutine was first defined? by shmem (Chancellor) on Feb 16, 2009 at 13:31 UTC
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]
Re^6: Is there a way to access the name under which a subroutine was first defined? by ELISHEVA (Prior) on Feb 16, 2009 at 14:20 UTC


Problems? Is your data what you think it is?
	PerlMonks