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; ... };
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 :-)
In reply to Re^3: Real live usage of inheritance?
by adrianh
in thread Real live usage of inheritance?
by BUU
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |