in reply to OOP private functions
The Perl language, AFAIK, doesn’t really have the notion of “a private method.” The convention that I have generally seen used is that methods which are considered to be private have names beginning with an underscore, e.g. sub _private { ... But this is only a human convention.
I also think that it is generally advisable to let these things be methods, partly to be consistent within the package. (After all, if they are subs that are defined within a package that has been blessed (i.e. “a Perl ‘object’,”), then they certainly can and might be called as a method, so they should probably just expect it. Basically, that just means expecting “yourself” (e.g. $self) to be arriving as the first, implied parameter. But, if you consistently do things in that way, you will be doing what I think most of your colleagues and successors will have come to expect.
Now, let us say that you do have a slew of pure-Utility routines. Every app does. So, what I would do (have generally seen done, and copied it ...) in that case is to define a Utility package (by some app-specific name), and, furthermore, to use specific subroutines out of it. For example:
use My_Utilities qw(foo bar bletch)
Or, maybe, declare that none of the routines are to be imported, and then reference the ones that you want with a fully-qualified name, like this:
use MyUtilities ( )
...
my $x = MyUtilities::bletch();
The idea here being that, since My_Utilities might have a whole bunch of generally-unrelated and commonly-named functions, you want to make it clear to your Gentle Reader (and to Perl) exactly where those functions can be found. You do this just in case someone who follows you needs to know what bletch() does, and just in case you’ve been smooshed by a bread-truck (or, been hired by Google ... let’s paint happy-trees here ...) since that time. Geeks would say, “to avoid polluting the local namespace.”
|
|---|