Bad things happen in real code all the time, and it's not an argument for the wholesale banishment of certain tools/techniques, but rather a case for better education. In this example, the possible errors are easily obviated by a correct choice of syntax given a very particular set of conditions. If the list parsing is getting munged using indirect invocation, then use direct invocation, or employ parentheses appropriately.

Respectfully, I must say I'm surprised that so many old timers would argue to avoid a feature whose negative consequences are so easily corrected.

but rather a case for better education

The "better education" you are asking for is what we are telling you. "Don't use IO notation - it's broken, at unpredictable times for the lay user".

The precise definition of when it is broken requires an understanding of the symbol table and things seen so far in the current compilation unit. Since direct-object notation always works, and indirect-object notation is sometimes broken at hard-to-describe times, what's wrong with a wholesale ban?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

So the bottom line for this wierd behavior is that modules referenced in indirect method invocations must be compiled before the compilation of the invocation. Given that the vast majority of modules are used this is a problem occurring in fairly rare instances.

It also seems like a problem that could be fixed with some additional smarts added into the compilation phase. If during compilation new modules are discovered after the BEGIN phase -- as in the example discussed below by dws and tye -- simply make a pass over the compiled code again to correct the misinterpretations. Or simpler, issue a warning in such cases.

In any case, I've seen indirect notation used successfully in too many tens of thousands of lines of OO Perl to be convinced that it's "a failed experiment".

---

"The dead do not recognize context" -- Kai, Lexx