I would argue that if the base methods are truly private, they should have been implemented as lexically scoped closures (declare my $init = sub { }; at the top of the package), not as a regular subroutine.

(Niggle: Making a subroutine lexically scoped doesn't mean it is a closure.)

Since most of the time all you want with a private method is to prevent subclasses breaking because they override it, there are a couple of other ways of protecting yourself without using anonymous subroutines.

package Foo;

sub _my_private_method { ... };

# we can just call it as a subroutine, then no matter
# what methods the subclass define we're okay.
sub my_public_method1 {
    my $self = shift;
    ...
    _my_private_method($self); 
    ...
};

# We can also root the method call in the current
# class
sub my_public_method2 {
    my $self = shift;
    ...
    $self->Foo::_my_private_method;
    ...
};
[download]

It'd be nice if we could do away with the _subroutine_name idiom all together, but Perl doesn't currently provide a way to do protected methods (except by doing some fooling around with caller and isa, and even then it's only a runtime error), so the leading-underscore trick is the next best option.

I've never come across people using the _method_name convention to indicate protected methods. Since most people use it to indicate private/implementation subroutines I'd probably consider it bad style myself.

However, since I tend to find protected methods to be a bit of a code smell anyway I don't really care :-)