private methods should not block a perfectly valid (inherited) public method from being called. The only way to get proper behavior is to not add the private method to the class's symbol table

I agree, kind of. I agree with the problem description and it's a fundamental issue with Perl's OO mechanism. I don't agree with your solution. (It's not completely clear you actually suggest people do use lexicals though.)

However, if you only want to make sure you don't block a parent method you can proxy the method call using goto &subname; (and possibly override can if there is any uncertainty as to whether the parent method exists or not), like

sub baz { # baz is private ...
  goto &{$_[0]->can('SUPER::baz') || \&error}
    if caller ne __PACKAGE__;

  return "Hello from Bar::baz (private)";
}
[download]

But this solution only solves half the problem with having private methods. It doesn't solve the problem of a child accidentally hijacking the call. So for me it's not good enough to make it worth the trouble.

My real issue with the lexical approach is this. If you extend your concept, then you can't write or import utility functions either, as they might block a parent's methods. You'd only be allowed to put public methods in the symbol table. But that's just too much a mess. So unless you use an OO framework that solves this for you, you just have to make sure you don't have private methods or (imported) functions that clash with any parents' method. It adds some danger, but subclassing a class you don't control yourself is already dangerous for several other reasons.

This is my rationale behind the paradigm described here, which takes the middle road:

1. call private methods as function (no risk of hijacks)
2. don't name public methods with a leading underscore (always safe to add _func:s, if you follow (1))

lodin