|P is for Practical|
Re^3: brian's Guide to Solving Any Perl Problemby demerphq (Chancellor)
|on Feb 07, 2005 at 15:33 UTC||Need Help??|
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:
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.