Beefy Boxes and Bandwidth Generously Provided by pair Networks RobOMonk
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

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

by demerphq (Chancellor)
on Feb 07, 2005 at 15:33 UTC ( #428694=note: print w/ replies, xml ) Need Help??


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

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.

---
demerphq


Comment on Re^3: brian's Guide to Solving Any Perl Problem
Select or Download Code
Re^4: brian's Guide to Solving Any Perl Problem
by Tanktalus (Canon) on Feb 07, 2005 at 15:51 UTC

    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.

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://428694]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (18)
As of 2014-04-16 21:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (434 votes), past polls