Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re: When to use Prototypes?

by John M. Dlugosz (Monsignor)
on Nov 10, 2001 at 01:47 UTC ( [id://124490]=note: print w/replies, xml ) Need Help??

in reply to When to use Prototypes?

FWIW, my reason for using prototypes in a situation like this:
sub helper ($$$) { ... sub foo { # code that calls helper
is because it does check the prototypes, since it's not a member dispatch or anything like that.

Specifically, if I add a parameter to the helper (or remove one) as I tinker with the code, the compiler will catch any uses I didn't update.

Basic idea: in situations when they do offer checking, why not give the compiler all the information you can?


Replies are listed 'Best First'.
Re (tilly) 2: When to use Prototypes?
by tilly (Archbishop) on Nov 12, 2001 at 15:50 UTC
    Here is an answer to your rhetorical question.

    The problem with using prototypes is that you are making assumptions for the person using your code about exactly how they are going to use it. Prototypes have many silent, nasty and unexpected side-effects. For instance perhaps the person using your code wants to have the parameters in an array. Oops, they need an array slice, but may not understand why. Perhaps they want to dynamically decide what goes into your second argument and so use a trinary operator. Oops, not allowed by the prototype, you need to use temporaries. Perhaps they are returning the output of a function to decide what your parameters should be. Oops, not allowed by the prototype, you need a temporary array and then a slice. Either that or multiple temporary scalars.

    None of these are very intuitive bugs for me to figure out. Nor when I have to bring someone up to speed on Perl do I want to waste energy on explaining the whys and wherefores of prototype-caused errors. It is simpler to just pretend that they don't exist.

    So using them, even when the usage is clear, is problematic at best. It is, in fact, very easy to achieve the same basic effect without the side-effects by a run-time check inside of the function. And the same approach will also work inside of method calls. It works no matter what order in your file the functions are declared in. Consistency and flexibility are Good. Making assumptions for your caller is Bad.

    But there are more reasons not to use prototypes for checking. When you use prototypes, you are forcing yourself into a single positional style of programming. You have put on a blinker where you are disregarding the possibilities of list-based constructs, or the use of named parameter processing. But I find that using positional logic is inherently buggy (people make mistakes with what order parameters go in), and I find tremendous flexiblity in using dynamic list-based approaches where applicable.

    So I find the win from prototypes to come with problems at best, and at worst trying to get it limits the kinds of solutions that can be tried. In other words they get me coming and going.

    All of this is why when this topic came up what I said in chatter was, Given the choice, I would refuse to work with a programmer who understood how Perl's prototypes work, understood the gotchas, and used them liberally anyways. It would be a cognitive mismatch. What I mean by that is that working with that code would be a constant source of frustration for me. And I simply would not want to do it.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://124490]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others studying the Monastery: (5)
As of 2024-04-21 09:24 GMT
Find Nodes?
    Voting Booth?

    No recent polls found