Re: Declaring Subroutines

[Sherlock]

Well, according to everything I've read, there are two basic benefits of prototyping your functions:

1. Allows user-defined subfunctions to behave much like the built-in Perl functions, such as time.

2. Allows the programmer to leave out characters, such as parenthesis and back-slashes (for references).

Personally, I don't feel that either of these benefits are really worth the trouble of prototyping my subfunctions, but if you'd like some more material to look at that shows a few examples, try this: Prototypes in Perl or a recent post: calling sub routine problem?.

- Sherlock

[tye]

This late in the thread, no one will probably see this, but...

I've seen several places here that have confused using prototypes with predeclaring subroutines. As I note in (tye)Re: A question of style, predeclaring your subroutines allows you to catch typos in subroutine names at compile time but only if you don't use parens when you call your subroutines. This can be a big win in some cases.

Prototypes can be used to catch other types of mistakes at compile time but the consesus is that they aren't very good at that and come with significant other problems that make their use for that purpose rarely (if ever) desirable. It is easier to make a case for using prototypes to create constant subroutines or to allow the use of bare code blocks in things that you want to have an interface similar to grep and map.

You can also use prototypes to cause arguments to be passed by reference rather than by "alias" (which looks like "passing by value" unless you modify elements of @_ directly) but many consider this a bad idea, me among them.

        - tye (but my friends call me "Tye")