in reply to Private and Protected class methods

There are no end of solutions to make method subs private, the most common one I've seen being some variation on:
sub _private_sub { die "_private_sub is private!" unless caller eq __PACKAGE__; # private stuff # }
The result is that only the package where _private_sub is defined can invoke it as a method. I've used this in the past where I found it sensible, and it has always worked well enough.

While this is a common way to implement private method, it is completely wrong.

If the perl method dispatcher encounters a private method, it should not die, but instead it should skip it an continue the dispatch. Take this pseudo-perl example:

package Foo; sub bar : public { ... } package Bar; use base 'Foo'; sub bar : private { ... } package Baz; use base 'Bar';
Now if under your scheme, this code:
Baz->new->bar;
would die, but that is not correct, it should succeed and call Foo::bar.

Method dispatching which includes Private/Protected/Public can have many subtle edge cases, some of which are not easily (if at all) solveable with the basic mechanisms provided in perl.

-stvn

Replies are listed 'Best First'.
Re^2: Private and Protected class methods
by radiantmatrix (Parson) on Sep 07, 2006 at 15:01 UTC

    That's an excellent point! Thank you!

    It seems like to do protection "properly", one would need some external knowledge of whether subs were supposed to be protected or not -- and that seems like a lot of work. I will be bringing this up with the design team for sure.

    ++!

    <radiant.matrix>
    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    I haven't found a problem yet that can't be solved by a well-placed trebuchet