Re: Lexical pad / attribute confusion

[adrianh]

Thanks to fever, shotgunefx, Aristotle and diotalevi for helping illuminate the areas of my misunderstanding.

Summary time - and one more question ;-)

Why can't the implicit call to MODIFY_HASH_ATTRIBUTES in Foo see %foo in perl 5.8? The attribute routine is being called at runtime so the hash should have been declared and be in the pad?

Because the hash doesn't come into scope until after the assignment, otherwise things like my ($x,@y,%z) : Bent = (@y); won't DWIM (thanks to Aristotle for pointing this out.) Obvious in hindsight.

<update date="20030104">You can also use Attribute::Handlers::Prospective to get the name of a lexical variable</update>

Why can INIT see %foo and %bar? They are not in the scope of the INIT subroutine and, since they are in their own blocks, they should not be visible from the file-scoped pad (the last call to dump_lex doesn't show them)?

Because you don't get a separate pad for { block } scope - only for subroutine and file scope (thanks to fever for pointing out Elian's explanation.)

INIT (and BEGIN, CHECK & END) are called outside of the normal "runtime" context where everything in the pad is visible.

This all makes some vague sort of sense - so I now have a handle on what is happening. However, I don't really understand why it's happenning.

New question: Why are BEGIN et al called in this odd context where they can see everything in the pad?

Is this just an accident of implementation, or is there a reason?

I find the fact that:

use strict;
use warnings;
use PadWalker qw(peek_my);

CHECK { peek_my(1)->{'%foo'}->{answer} = 42 };

{
    my %foo;
    print $foo{answer}, "\n";
};

outputs 42 somewhat counter-intuitive.

[diotalevi]

As near as I can gather - it's just an innermost scope. I took the trouble to write a quickie XS library (Devel::DebugScope) to dump some of the scoping variables. You can download it here if you like: http://198.144.10.226/perl/Devel-DebugScope-0.01.tgz. I used it to instrument your code and it corroborates that CHECK and friends have an apparent lexical scope equivalent (or greater for BEGIN) than the inner scope. The key values to look at are scopestack_ix and savestack_ix (I guess).

use strict;
use warnings;
use PadWalker qw(peek_my);
use Devel::DebugScope qw(dump_scope);

CHECK { print "CHECK\n";
        Devel::DebugScope::dump_scope();
        print "\n\n"; }
CHECK { peek_my(1)->{'%foo'}->{answer} = 42 };

print "Runtime outer\n";
Devel::DebugScope::dump_scope();
print "\n\n";

{
   my %foo;
   print $foo{answer}, "\n";
   print "Runtime inner\n";
   Devel::DebugScope::dump_scope();
   print "\n\n";
};
__DATA__
CHECK
scopestack_ix:      5
savestack_ix:       21

Runtime outer
scopestack_ix:      3
savestack_ix:       10

42
Runtime inner
scopestack_ix:      5
savestack_ix:       15

---

Fun Fun Fun in the Fluffy Chair

[adrianh]

++. An excellent demonstration of what is happening.

Now if only somebody can tell me why :-)

(or point to the relevant docs if there are any).