Because Perl doesn't have true method privacy, Perl developers can mean more than one thing when they talk about a "private" sub/method.

Sometimes they mean a sub which is not to be used at all outside the module it was defined in. In these cases, I'd suggest you should at least consider making it into a coderef instead of a named sub, so that it cannot be used elsewhere (PadWalker trickery notwithstanding).

That's one way, but I prefer the "contract instead of shotgun" way explained in perlmodlib:

Perl does not enforce private and public parts of its modules as you may have been used to in other languages like C++, Ada, or Modula-17. Perl doesn't have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren't invited, not because it has a shotgun.

The module and its user have a contract, part of which is common law, and part of which is "written". Part of the common law contract is that a module doesn't pollute any namespace it wasn't asked to. The written contract for the module (A.K.A. documentation) may make other provisions. But then you know when you use RedefineTheWorld that you're redefining the world and willing to take the consequences.

IMHO, modules should not try to prevent calling or inherting their private methods. They should clearly document that it is a stupid or very stupid idea to do so, and that future implementation will break code that relies on behaviour or even existence of private methods.

Also, modules using OOP should not have any private functions, but they should use methods documented as private instead. This way, I (as a user of the module) have the freedom to mess with the modules internals without resorting to monkey-patching, simply by inheriting from the module and fix what looks broken.

Yes, this is against the basic ideas of OOP. No other class or object should mess with the "private" attributes or methods of an object, and only an exclusive circle of classes should be allowed to mess with "protected" attributes or methods.

BUT: In the real world (as opposed to people drawing inheritance diagrams all day and all night), you sometimes have to break the rules to get things done. (See Re: DBD::CSV - how to I coax it to read BOM prefixed files? for a real-world example.)

Alexander