in reply to (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).

my $run_end = sub {
   my $self = shift;
   ...;
};

sub some_public_method {
   my $self = shift;
   ...;
   $self->$run_end();
}

[download]

Unless it's really obvious what it does, document its purpose in comments. The question of whether you should test it or not becomes moot — it cannot be used outside the module, so your test scripts can't directly touch it anyway. Any problems which affect the rest of the module should be exposed when you test the public API. Any problems which don't affect the rest of the module probably don't matter.

Other times, there are functions you have in one class/module that are not intended to be called by end users, but might be called by other classes/modules within your distribution, or overridden by subclasses within your distribution. This is racism. Don't do this. Well, okay, not racism, but that got your attention. It's still discriminating against other modules/classes because they weren't written by you. If it's a function/method which you have found useful/necessary, then other people might find it useful/necessary too, so make it part of your public API. Okay, so maybe it's pretty obscure and 99% of end users won't need it, and you don't want it cluttering up your documentation, but in that case, mention it in a separate "ADVANCED API" section of the documentation (perhaps even in a separate pod file) or document it fully in the comments, making it clear that it's a supported albeit obscure part of your API.

See also: the middle part of my presentation at the 2014 London Perl Workshop (and there's a cringy video of it on YouTube too).

toby döt ink

Replies are listed 'Best First'.
Re^2: (How) Do you document/test your private subroutines?
by afoken (Chancellor) on Nov 08, 2018 at 21:37 UTC

    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". ;-)
[reply]
[d/l]

      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]
Re^2: (How) Do you document/test your private subroutines?
by LanX (Saint) on Nov 09, 2018 at 00:47 UTC
    >  If it's a function/method which you have found useful/necessary, then other people might find it useful/necessary too, so make it part of your public API
    • I don't want to expose implementation details which will change in the future
    • I don't want to clutter the public API with obscure functions
    • I don't want to have compatibility discussions because I have to rename or drop an internal helper
    • I don't want the overhead to document something which is just a temporary hack for an early version / proof of concept.
    If someone finds a non API function useful after reading the source, he's still free to use it at own risk.

    The risk is obvious by the fact that it's NOT part of the public API.

    Occasionally I notice that internal functions might be useful for others, in this case outsourcing them to another module appears to be a better strategy.

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

[reply]

In Section Seekers of Perl Wisdom