Experience strongly suggests that if you use descriptive method names, collisions are rather rare, documentation is never accurate, and it is as easy to search code for private methods as it is documentation. (Besides, I'm always going to search the code in the end because I don't trust the documentation.)

Furthermore no amount of documentation can protect you if the base module's implementation changes and it now needs a new private method that might intersect what some subclass is using.

This is part of what I was referring to at Re^2: Private Methods Meditation. And there is no perfect solution to it. However after you use descriptive method names and have decent test suites, the problem virtually goes away. If you furthermore have somewhat decent designs, the issue becomes rare to the point of being an endangered species.

I'll continue my practice of not documenting private methods in POD. They are in source code, and possibly in regular comments when needed. That is good enough.

Furthermore no amount of documentation can protect you if the base module's implementation changes and it now needs a new private method that might intersect what some subclass is using.

You hit the head of the nail here. That's why you shouldn't use methods calls on "private methods" (update: private methods in the java sense, not just "non-public" methods)--to avoid that intersection with any subclass. Though, you alrady have a large code base that uses $self->_private you can document these methods (just that they exists and are called as methods with suffice) instead of patching every methods call. (And then you of course should stop using method invocation on private methods.)

ihb

Read argumentation in its context!

That's why you shouldn't use methods calls on "private methods"--to avoid that intersection with any subclass.

That choice doesn't always make sense.

It is common for a class to use appropriately placed method calls as convenient "hooks" to let subclasses override behaviour. In fact this is a decent design strategy, and I've been known to recommend it.

But these methods are not public. That is, they are not meant to be part of the public API that the class and its subclasses present to the user. Rather it is part of the private API between the class and its subclasses. So they are private (at least to some extent). But they really have to be done as method calls, because the entire point of the method is to be overridden appropriately in subclasses.

What now? Well one choice is to decide to never add such hooks once the module has been written. In fact this is exactly what the open-closed principle tells you to do. However if you maintain an evolving system over time and adhere to that strictly, then you'll find that this encourages developing a maze of classes that is a maintainance problem of its own.

Another strategy is to say that you'll sometimes accept the up front risk and go ahead anyways. (Making design tradeoffs is, after all, the job of the programmer.) This makes particular sense if you have a closed code-base and are willing to grep it to make sure that you won't create a conflict. But even if you don't, it is sometimes still an acceptable cost. Particularly if you have a stated convention that all such methods will start with a particular substring.

In any case it takes coordination between the maintainer of the class and subclass to make this work and continue to work. If you don't feel comfortable with that, then you shouldn't be subclassing.