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

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.

Comment on Re^5: 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^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
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	[reply] [d/l] [select]

Replies are listed 'Best First'.

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

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

[reply]
[d/l]
[select]