in reply to subroutine prototypes still bad?

The problem with prototypes is not that they are poor form, it's that they don't do what most people expect from their experience with Java or C. They are usually unnecessary in Perl, and if misused are the source of confusing bugs. Bugs particularly confusing to the person who wrote them.

Perl prototypes override normal parsing of a sub's arguments. They can be used to prevent the flattening of arrays, for instance. Normally, in foo(@bar,@baz), the two arrays will be merged into a list of both their contents in order. If foo were given the prototype '\@@', however, @bar is treated as a unit, joining the argument list as a reference to itself. The foo() function will treat its arguments the way that push does.

The empty prototype is a particularly interesting one. It causes Perl to try to unfold sub parsing and produce a constant at compile time. It can have profound effects on how a statement is parsed.

I'm not clear on what you mean by your reference to strict and warnings. As far as I know, those are unrelated to prototypes, other than a few warnings which indicate that a prototype will not be honored or a sub call has ambiguous syntax.

After Compline,
Zaxo

Replies are listed 'Best First'.
Re^2: subroutine prototypes still bad?
by doom (Deacon) on Jun 13, 2007 at 17:11 UTC
    The way I put it is that prototypes let you write routines that act more like some of perl's built-ins. For example, you might want to write something that acts like this: 
    # deal from the middle of the deck
my $card = pop_random( @deck );

    [download]

    And the real trouble with writing code like this is simply that it doesn't behave like regular perl code. A non-perl expert reading that line of code is likely to feel a vague sense of disquiet, a sense that they don't quite know what's going on. A perl expert reading it is going to immediately want to see the definition of pop_random, to make sure the prototype was used right.

    On the other hand, the slightly uglier semantics of pop_random( \@deck ); is much less likely to throw anyone off.

    (And yes, it's unfortunate that these were called "prototypes": I didn't understand what they were for a long time, because I expected them to be hints to the compiler to help catch errors if the wrong kind or arguments were passed.)

[reply]
[d/l]
[select]
Re^2: subroutine prototypes still bad?
by Anonymous Monk on Jun 13, 2007 at 00:26 UTC
    So this means that the interpreter prefers to see all subroutines to be defined prior to being called?
[reply]

      Yes, if they are prototyped. Otherwise, no.

      After Compline,
      Zaxo

[reply]
        Don't you mean the converse? Placing prototypes before subroutine calls means the subroutine definition can occur much later, whereas not using prototypes means that subroutine definitions much be encountered prior to those subroutines being called. Not to be pedantic, I'm simply trying to understand the ramifications of warnings & strict.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom