NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Perl or Java? (Score:2)
On the other hand, it's Java all over again. Every time I look at a Java program, I see statements like import java.io.* and the like. A few lines later, I see references to classes I've never seen before from one package or another, and I don't know where to go when I'm looking up methods on some interface like XMLReader or some class like HashMap. Because the package prefixes are stripped, I've lost all context as to what's what. I wouldn't have such a severe reaction if I programmed in Java all the time, but that's like saying the way to stop making your head hurt is to keep banging it until you can't feel the pain.
This pattern is not an absolute good or bad thing. You can't get anything done in Java without using dozens of classes from at least half a dozen packages, so figuring out which class belongs in which package just by reading the source code is more difficult than it should be. So maybe the pattern isn't bad, maybe it just turns sour in Java where you can't get up to stretch your legs without touching 7 interfaces and 15 classes from some or all of the packages you've imported.
So just keep that in mind. If your code is using two or three classes that are all explicitly aliased, it's probably a good thing. But keep the counter example of Java in your mind, so you don't repeat that pattern-gone-awry.
Reply to This
Re:Perl or Java? (Score:2)
This is somewhat different from the Java model (I had considered implementing that but I abandoned the idea as causing more problems than it solved [perlmonks.org]). Java is frustrating because, as you point out, you can silently bring in tons of namespaces and not know their origin. However, class.pm does this one module at a time. You can always glance at the code at the top of the package to see where the package comes from.