Don't ask to ask, just ask | |
PerlMonks |
Re^2: (How) Do you document/test your private subroutines?by afoken (Chancellor) |
on Nov 08, 2018 at 21:37 UTC ( [id://1225463]=note: print w/replies, xml ) | Need Help?? |
That's one way, but I prefer the "contract instead of shotgun" way explained in perlmodlib:
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
-- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
In Section
Seekers of Perl Wisdom
|
|