Putting all private methods together after the public methods would be just nonsense. What's easier to read, alternative 1:

sub function1 {
  #...
}

sub _aux_function1 {
  #...
}

sub function2 {
  #...
}

sub _aux_function2 {
  #...
}

sub function3 {
  #...
}

sub _aux_function3 {
  #...
}
[download]

Or alternative 2:

sub function1 {
  #...
}

sub function2 {
  #...
}

sub function3 {
  #...
}

sub _aux_function1 {
  #...
}

sub _aux_function2 {
  #...
}

sub _aux_function3 {
  #...
}
[download]

And if you're still not convinced, try with a larger example, preferably with pod in the middle.

Does anyone else hate the way method names with leading underscores look?

UPDATE: In an even different situation in which I want a "private portion of a namespace" since I'm only using it as an "anonymous tool" I still use those leading underscores, e.g.:

sub is {
    return bless \shift, '_hidden';
}

sub _hidden::in {
    my $s=${shift,};
    $s eq $_ and return 1 for @_;
    0;
}
[download]

You mean instead of

my %dispatch;

$dispatch{foo} = sub { 
  ...
};

$dispatch{bar} = sub {
  ...
};
...
[download]

?-)

Jenda


We'd like to help you learn to help yourself Look around you, all you see are sympathetic eyes Stroll around the grounds until you feel at home    -- P. Simon in Mrs. Robinson

I mean like this:

my %dispatch=(FOO => \&_foo,
              BAR => \&_bar,
              # ...
              LAST => \&_last);

# And at the end of the script:

sub _foo {
    # ...
}

sub _bar {
    # ...
}

# ...
[download]

(Yes, I may have done as suggested by you instead.)

That means, you give up encapsulation. If you allow private methods to be called, they aren't private, and if you change the interface or functionality of such a method, or remove it all together, you've just broken backwards compatability.

OO without encapsulation doesn't make any sense to me. Then it just becomes syntactical sugar to be able to use cool looking arrows.

OO without encapsulation doesn't make any sense to me. Then it just becomes syntactical sugar to be able to use cool looking arrows.

Many, I amongst them, would argue that your statement is incorrect. You have used the word "encapsulation" where, from the context, you really meant "information hiding".

That may seem like a facetious argument, but this Encapsulation is not information hiding may change your mind.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

Agreed. Private methods/variables should have no reason to be called outside a class. If necessary, simply make a public accessor that calls that private method/variable.

I personally use underscores because it is helpful from a visual standpoint. Especially when there are no built-in security measures in place to hide variables and methods (not include closures, but that's not what I'd consider a "built-in" way to hide things, no offense to closures, of course).

Even still, coming from Java, I used them there. You simply get used to it, and while I agree it is not the prettiest thing in the world, I've seen worse :)

Howdy!

That means, you give up encapsulation. If you allow private methods to be called, they aren't private

The first claim is non sequitur. The second depends on a specific connotation of "private" that does not necessarily hold. Further, the concept of "allowing" methods to be called implies some way to prevent it, which is decidedly non-Perlish.

Moving onward, you can troll through the namespace of a module to see what CODE references you can find in the name space. That then gives you names of subroutines. If you want to actively prevent methods from being called under certain circumstances, you can use caller() to try to decide if the caller is acceptable, and barf otherwise. In general, that is a lot of work for little to no gain. Further, that sort of "protection" can still be circumvented by clever hackery -- hackery that has no place in a "finished" product, but possible hackery nonetheless.

yours,
Michael

What do you like to use to distinguish between the public and private parts of your modules?

Heh. Heh-heh. He said "private parts".

It all boils down to encapsulation. With proper encapsulation (and documentation), users never need to look at the source to get their programs working correctly. Document well, encapsulate well, and you don't need "leading underscore" conventions (doesn't that smell awfully Hungarian?).

This implies also that I don't use POD::Coverage.

This implies also that I don't use POD::Coverage.

There is no reason you cannot still use Pod::Coverage. All you need to do is to tell it the methods which you decide are private, and it will skip them. You basically just pass in one (or more) of these options to the constructor:

private an array of regexen which define what symbols are regarded as private (and so need not be documented)

also_private items are appended to the private list

trustme an array of regexen which define what symbols you just want us to assume are properly documented even if we can't find any docs for them

And of course all these options are available thougth Test::Pod::Coverage as well.
-stvn

That's sort of what I do too. Give the public methods pod and just give the private methods comments. I'd like to just go with that and drop the underscores.