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.

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.

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