in reply to Re: (How) Do you document/test your private subroutines?
in thread (How) Do you document/test your private subroutines?

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

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^3: (How) Do you document/test your private subroutines?
by tobyink (Canon) on Nov 12, 2018 at 14:31 UTC

    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.

    toby döt ink
[reply]
      > But I sure don't want to override any of them accidentally

      underscore _convention() ?

      > That alone should warrant making anything you truly need to be private into a coderef.

      But coderefs can't be used for protected routines.

      Anyway, I have no issues with documenting private routines, as long as it's clear they are not part of the compatibility "contract".

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

[reply]
        > underscore _convention()

        That's the problem. If the parent class defines _frobnicate but doesn't document it, you might accidentally define _frobnicate in the child class (because underscore convention!) to do something completely different, and kaboom!

        ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord
}map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,

        [download]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom