Re: Re: Re: Subroutine Bewilderment

[Joost]

Note that we don't run into problems until we start introducing prototypes, which generally people say to "stay away from", which is fine, but with caveats...

Well... that's what prototypes are meant for: breaking the rules, and that entails you're taking the risk of confusing the users of your library, the perl parser, or both.

You can only 'stay away' from something for so long, and then finally you want to become one of those mythical people who 'really really really know what they are doing'

I understand your concern, but I can only repeat the above paragraph. The phrase "enough rope to hang yourself" comes to mind.

[doom]

Joost wrote:

Note that we don't run into problems until we start introducing prototypes, which generally people say to "stay away from", which is fine, but with caveats...

Well... that's what prototypes are meant for: breaking the rules, and that entails you're taking the risk of confusing the users of your library, the perl parser, or both.

I don't think this is a satisfactory summary of what prototypes are for. The way I would put it is that prototypes are included to let any programmer write something that behaves like one of the perl built-ins rather than a "normal" subroutine. They're there so that you can write things that work like

 $card = pop_random(@deck)

that deals from the middle of the deck instead of the top the way pop would.

As far as the main question is concerned, I can really only think of a couple of things to say, and they're pretty obvious. When there's always more than one way to do it, it's incumbant on the user of a subroutine to check the documentation, looking for examples of how to use it in the SYNOPSIS. And it's incumbant on the original programmer to document the code, and make sure there's a SYNOPSIS with decent examples in it.

If by some strange unheard of quirk of misfortune you're working with an undocumented code base, there's always the source...