in reply to Re: private sub routine
in thread private sub routine

Funny, saranperl asks one of his overly condensed interview questions without any further explanation and he gets answers with desperate interpretations like in a interview.

Is perlmonks an interview? Do we apply for a job?

You're thinking of "private" like in Java and most of the others of "private" like in lexical variables.

BTW: Googling for "private function" and "perl" quickly leads to perlmod

# here's a file-private function as a closure,
# callable as &$priv_func; it cannot be prototyped.
my $priv_func = sub {
  # stuff goes here.
};

[download]

So why do we answer a question which can be easily resolved with googling???

Cheers Rolf

Replies are listed 'Best First'.
Re^3: private sub routine
by Marshall (Canon) on Sep 03, 2009 at 01:07 UTC
    I didn't investigate saranperl's previous posts.
    Yes, there is a way to make a Perl "private sub".
    The part that wouldn't be resolved via Google is that this is a bad idea in Perl. Now that's my personal opinion, but I'm sticking to it and for good reasons.
[reply]

      What makes it a bad idea?

[reply]
        Well off the top of my head...
        1. There is no need to do this! That's a big reason.

        2. This is an overly complex calling syntax that is non-standard versus Perl norms. In general coding confusion into the program is not a good idea. That is an opinion. But I think that tricky non-standard things should be avoided.

        3. This would interfere with some Perl debugging features.
         $subname = sub{...blah..} is ref to an anyon sub. Consider:

        sub whoami  { (caller(1))[3] };  #returns name of the sub that called 
+this sub
sub whowasi { (caller(2))[3] };  #returns name of the parent of the su
+b that called this sub

        [download]
        In the case of $subname, there is no "name". I sometimes use code like whowasi() for debugging to trace back to where some weirdo sub input came from. If you are proposing to put a large number of anon subs in a module, this kind of idea breaks.

        Just because something is possible, doesn't mean that you should do it.

        For me: no need, overly complex, non-standard is enough. As I mentioned above there are ways to regulate what sub names get "exported" from a module which is a subset of the names in the package symbol table. There are naming conventions for OO methods like (_xyx is private). All that is "good enough".

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom