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 [...]
[...] 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.
So I, as a module author, should provide an interface which people might need to rely on to accomplish what they need, and document that it's stupid to use it? That might be less work for me in terms of ensuring API stability, but for end users, I think they'd prefer I documented those methods (however obscure they might be) and committed to at least attempting to keep the API stable.
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.
The reasons for this are not just theoretical purity; there are very good reasons for classes to have no undocumented methods. And subclassing is the biggest one of those. If I'm writing a subclass of your class, I might want to override some of your methods deliberately. But I sure don't want to override any of them accidentally, so I need to know what they're all called. That alone should warrant making anything you truly need to be private into a coderef.
In reply to Re^3: (How) Do you document/test your private subroutines?
by tobyink
in thread (How) Do you document/test your private subroutines?
by stevieb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |