Re: brian's Guide to Solving Any Perl Problem

[sfink]

Any reason why you type all of

require Data::Dumper;
print Data::Dumper::Dumper(...);

rather than

use Data::Dumper;
print Dumper(...);

?

Also, in your particular example, I always prefer the output of Dumper(\%hash) to that of Dumper(%hash).

Recently, I've been sometimes using the even-less-typing-required use YAML; print Dump(...), but that requires actually installing YAML first. And I'm still not nearly as used to the YAML format as I am to Data::Dumper format.

[brian_d_foy]

Most style guides I work under ask for the full package name of external functions, and I generally agree with that. I have found that I shouldn't expect others to know where all of these functions came from. Also, I don't have to keep track of every modules exports. Some decided to have the same names for things. Remember: @EXPORT is evil.

This way would cause a problem if someone wanted to use YAML as a drop in replacement, though.

[demerphq]

Most style guides I work under ask for the full package name of external functions, and I generally agree with that. I have found that I shouldn't expect others to know where all of these functions came from.

I totally agree that you should know where a subroutine comes from, but i pretty strongly disagree with using FQ package names to acomplish that, and I definately don't think that using require is wise at all. There are two reasons for these opinions. The first has to do with encapsulation. When you use FQ subroutine names you are totally violating the encapsulation of your package code. Take the following contrived example:

Package Foo has two subs defined, BarA() and BarS(), BarA is defined for export, BarS is defined as a more or less private internal version. You want to use BarA(), so you write Foo::BarS() and then wonder why your program A) doesnt fail when it gets to that line, and B) why its just done something horrible to your data that BarA() promises not to do.

With use and explicit exports you dont have this problem. You EXPLICTLY request the export of a subroutine. Assuming the private version isnt in @EXPORT_OK then youll never blow your foot off by saying:

use Foo qw(BarS);

A second serious objection i have to using require like this is that requires are run time constructs. Your program could have half finished before it gets to the require only to fail, leaving your program in the tough position of having to recover, something that it may be bad at, which could leave your overall system in an indeterminate state. Wheras with use the error would have occured at compile time, and would have happened before almost anything else did, a situation much easier to recover gracefully from.

My personal feeling is that require is a badly named keyword. Most often when I see the keyword in use is when the code doesnt in fact "require" the module at all, but rather would just prefer it to be there. AFAICT when code really requires a module its much better to use it instead.

Anyway, good thread. Thanks.

[Tanktalus]

Perl is not a language of dictatorship. If you want to blow your own foot off, you can. There is no "private" scope modifier - just a convention of a leading underscore on otherwise private function names. But, if you know what you're doing, you're completely free to call them.

I firmly believe in caching, delayed evaluation, and uncluttered namespaces. Caching means I don't calculate the same value twice if it can be helped, especially if the calculation is expensive (note that "calculation" does not just mean "arithmetic" - calculating the list of files that match a certain regexp from across an NFS share is a calculation - and an expensive one at that).

Delayed evaluation means that I don't calculate everything up front - if, in the current run of the program/script/module, I don't need certain information, I don't calculate it at all. This follows into loading other modules: if there are valid codepaths which may not need another module, I usually simply "require" the module during the calculation.

And uncluttered namespaces means I like to import as little as possible to make it less likely that I get any collisions.

Of course, this is all simplified by the fact I also use OO as much as possible - objects cache their own calculations (if that makes sense), I load those modules as needed (OO doesn't solve your compilation-failing scenario though), and OO modules rarely export functions to clutter the caller's namespace.

This doesn't say I never export functions in my modules. Just that there has to be a really good reason to do so.

[tye]

Most style guides I work under ask for the full package name of external functions

What an awful idea. Just being explicit about what you import from any module you use is a much better idea. @EXPORT is evil but @EXPORT_OK makes for easier-to-read/-write code and provides reasonable interface verification (at compile time, no less). demerphq already said all of this, but I just boggle at the sentence I quoted so I had to chime in against such insanity.

[JavaFan]

If the importing module uses an explicit import list, @EXPORT isn't any more evil than @EXPORT_OK is. @EXPORT provides a default list to import. It's up to the user of the module to decide whether to use the default or not. I very seldomly write a module that has an empty @EXPORT and a non-empty @EXPORT_OK. Not providing defaults isn't very friendly in my book.

[Courage]

I agree that @EXPORT is evil but in your case you miss possible invocation of "import" function, which could do some necessary setup.

Yet you don't do require strict;, don't you?

[demerphq]

use YAML; print Dump(...), but that requires actually installing YAML first.

You might try installing Data::Dump::Streamer (along with the DDS alias.) Then its just use DDS; Dump(...); :-) Its a Data::Dumper replacement (not drop in) which does a more or less breadth first dump of your data so its usually a lot easier to read, especially for cyclic and selfreferential data structures.

[Anonymous Monk]

use YAML; print Dump(...), but that requires actually installing YAML first.

You might try installing Data::Dump::Streamer (along with the DDS alias.)

So, your suggestion to sfink's drawback of having to install a module is to install a module?

[demerphq]

No, I misquoted, i meant to emphasize

And I'm still not nearly as used to the YAML format as I am to Data::Dumper format.

My point was that if you are going to install a module for better dumping you might as well install one that is easier to read. Of course honesty demands I point out that DDS requires XS and is quite slow (and doesnt build under one of the early 5.8 series, i think 5.8.0)