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".

<Flame-On!>

It also seems like a problem that could be fixed with some additional smarts added into the compilation phase.

So, you want the compiler to pick up the slack that you're causing because you want to use a syntactic arrangement that has been deprecated? How falsely Lazy.

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".

Ahh ... the old "I've-never-seen-it-fail-so-it-can't-fail" argument. Reminds me of the recent poll regarding favorite logical fallacies. I think I would've voted for this one. Arguing from personal experience is one of the worst arguments one can make, primarily because it's so seductive and it's almost valid. Even if you have read every single line of Perl code that has ever been written, you still would not be able to conclude that the IO notation is ok to use. It would still be a hypothesis. Maybe, it starts to approach "theory" status, but it's not "Law" status.

The only way to achieve "Law" status is to mathematically prove that the IO notation will work correctly in all instances. Unfortunately for your attempt, the counter-example has already been demonstrated. Sorry bout your luck!

"new" is not a keyword. As a method, it cannot use prototypes. The IO notation exists solely as a hack to ease the transition for C++ and Java developers. Larry has said that he wishes the hack had never been approved. Good'nuff for me.

As for it working in most cases ... to me, that's a testament to the skill of p5p and the flexibility of Perl, not an argument for whether or not the feature isn't a mis-feature.

<Flame-Off!>

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Ahh ... the old "I've-never-seen-it-fail-so-it-can't-fail" argument. Reminds me of the recent poll regarding favorite logical fallacies. I think I would've voted for this one. Arguing from personal experience is one of the worst arguments one can make, primarily because it's so seductive and it's almost valid.

The sentiments you express are exactly what I found troubling in merlyn's and Abigail II's remarks, which amounted essentially to the overwhelming two-part argument: "I have seen this not work, therefore you shouldn't use it". Well for a lot of people it does work, and my point is that we ought to figure out how to make it work even in these rare cases where people get bitten or at least work to increase understanding of its limitations.

While I might recommend that a newbie be careful when using indirection notation my own experience with it has been positive, and you can throw as many merlyn's and Abigails and Larry Wall's at me as you want but their mere luminescence is not an argument. To repeat dragonchild: I never claimed that these problems were not real, only that an outright ban was unnecessary, so kindly keep your flaming to yourself and don't lecture me on argumentation when you clearly haven't paid any attention to what my argument actually is.

---

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