http://www.perlmonks.org?node_id=1004359


in reply to Re^8: Moo and Spreadsheet::ParseExcel (explain?)
in thread Moo and Spreadsheet::ParseExcel

"Could you try explaining this again? In particular, what is the code outside of Moo that causes $_ to exhibit this problem? It probably doesn't help that I'm not clear on how 'undef' ends up in @roles (is the code that does that shown anywhere in this thread?)."

Moo::Role loops through the list of roles with a for loop, using the default loop variable, global $_. (Or rather it did, as this is now fixed.)

In for loops, the loop variable is an alias into the array. If you assign to it, the original array is altered. Thus within that loop, if $_ were assigned to, it would alter the list of roles.

Now, what happens within the loop? The role modules get required. And thus any modules that the role modules use get loaded too. And in all that code that gets loaded, somewhere, undef gets assigned to global $_. (And no, I don't know exactly where... Spreadsheet::WriteExcel has a number of dependencies.)

That's how undef gets into @roles.

"I'm also unclear how the 'uninitialized' warning causes the Role::Tiny module to fail (leading to a "Compilation failed") without producing an error message."

Role::Tiny has:

use warnings FATAL => 'all';
perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Replies are listed 'Best First'.
Re^10: Moo and Spreadsheet::ParseExcel (explain?)
by tye (Sage) on Nov 18, 2012 at 01:16 UTC

    Ah. Thanks. What I was missing was that there was an unspecified outer layer that was calling Moo::Role, not just the inner layer that also used Moo::Role (as well as Spreadsheet::ParseExcel).

    So it was a standard mistake of calling out to arbitrary code while using $_. And there is a spot somewhere in Spreadsheet::ParseExcel that it would be good to add local $_ to.

    - tye