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

"I have seen this not work, therefore you shouldn't use it".

Ummm ... that is a good argument as to why one shouldn't use a deprecated synactic construct which has the possibility of breaking previously-working code for unrelated reasons.

The point is that code should be as bullet-proof as possible. Rearranging the order of module inclusion should never break anything. Ever. Period. If, by using DO vs. IO syntax, I can mathematically prove that rearranging said order will not break my code and I can mathematically prove that it will by using IO ... it seems to me that it's a no-brainer.

Now, this argument may not be as critical to you, depending on the size and complexity of the applications you work with. In my opinion, once you get beyond, say, 10 minutes of explanation to a competent new-hire - that's when IO just shouldn't be used. Otherwise, it probably won't matter. (But, I'm not going to bet my money on that "probably" and anyone who bets their employer's money on that is, in my opinion, irresponsible.)

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