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.
A package not in a module... (Score:1)
1) Differentiation of namespaces within a program?
2) Private class/object definition/functions w/ no chance of re-use by other code?
3) Other motives?
Jon
Re:A package not in a module... (Score:1)
There are many other reasons, too. I don't have time now, perhaps others can mention some.
Warning: Crack use is up (Score:1)
As much of a style Nazi as I am about Perl, having multiple packages in a file is perfectly legimate if the packages are related. Many DBD modules do this. SOAP::Lite does this. When dealing with XML::Parser, you often need to define your own package for callbacks. It's convenient and often sensible. Packages are simply namespaces. They cost nothing to use. Would you rather have one big bookcase or several smaller ones? Depends on your dwelling.
Another guilty party (Score:1)
I've done similar things, but I tend to cordon them off inside an anonymous block.
Tell 'em to bugger off. (Score:2, Insightful)
Some that come to mind are small tie classes, overloads, and object classes. Also, when you want to "inline" a module for distribution purposes.
The camel is clear (Score:2)
I believe the camel says a package is usually a class, they usually have the same name, it usually begins with a capital letter, there is usually one package per file, a package is usually a module, and so on. Usually. Not always.
Anyone who's programmed Java knows sometimes you have extra classes in a file.
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Testing and POD, but still useful (Score:1)
The other reason is that if I stick it in a seperate file then I can document it with POD. I can't do that in the middle of some other class (and even at the end it looks wrong)
OTOH, sometimes you don't need to document something in the POD - I wouldn't enforce you to document every private method (you might want to hide the interface) and there