Consider:

use strict;
use warnings;

my $obj = bless {};

# As function
do_something ();

# As method
$obj->do_something ();


sub do_something {
    my ($self) = @_;

    if ($self && 'main' eq ref $self) {
        print "Called as method\n";
    } else {
        print "Called as function\n";
    }
}
[download]

Prints:

Called as function
Called as method
[download]

A sub is a method right, so I assumed its called like one.

Prototypes change how the parser interprets the syntax of a call when Perl compiles the program. It's easy to figure out which apply() function gets called when you write:

sub apply_arguments
{
    my ($item, @args) = @_;

    for my $arg (@args)
    {
        apply( $item, @args );
    }
}
[download]

It's much more difficult to figure out which apply() method gets called when you write:

sub apply_arguments
{
    my ($self, @args) = @_;

    for my $arg (@args)
    {
        $self->apply( @args );
    }
}
[download]

The appropriate method may not even exist at that point in the program.

I believe the difference is ambiguity. The procedural function is known and its signature can be examined and used. Depending on what you put in the signature, a %hash might be flattened into an @array, or converted into a \%hashref as it is shoved into @_. With a method call, you cannot be sure how a method call resolve until runtime, and by then it is too late to know what to do with the arguments.

In Perl Best Practices, Damien recommends never using signatures. This is both because they are not available in all situations, and because they are easy to mess up. They are not worth the risk of potential problems.

Personally, I like 'em. I don't use them for any OO work (obviously), but I do use them for procedural helper routines. This is because if I add or remove an argument and do not update it everywhere, I prefer to get the warning at compile time instead of something at runtime.

- doug

PS: Improved signatures is one of the perl6 things that I hope hurry up and get here.