Re^2: brian's Guide to Solving Any Perl Problem

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

[demerphq]

I think you've totally missed my points here. Im not saying that you shouldnt be able to do things that can blow your foot off. Im saying that if you want to avoid certain problems you should use the techniques that really help you avoid them and not use techniques that introduce just as bad, but harder to track down issues.

My point in simple is just: to avoid namespace clashes in your code you should use the module and you should EXPLICITLY import the subs you need. If you manage to explicitly import two different identially named subs then I dont think any amount of advice can help you, although the handy "sub redefined" warning will let you know the error of your ways. In short: I consider using FQ sub calling to be just as bad as implicitly importing them (actually IMO its worse).

[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?