http://www.perlmonks.org?node_id=428704


in reply to Re^3: brian's Guide to Solving Any Perl Problem
in thread brian's Guide to Solving Any Perl Problem

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.

Replies are listed 'Best First'.
Re^5: brian's Guide to Solving Any Perl Problem
by demerphq (Chancellor) on Feb 07, 2005 at 17:54 UTC

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

    ---
    demerphq