Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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:
outputs 42 somewhat counter-intuitive. In reply to Re: Lexical pad / attribute confusion
by adrianh
|
|