Re: Are prototypes evil?

[MrNobo1024]

IMHO, prototypes are a good thing. People sometimes complain about things like sprintf(@fmt_and_args) not working, but it is very rare to have both the format and arguments in the same array.

Now, let's see a sub where prototypes are very helpful:

sub dmap (&\@@) {
    my $cl = shift;
    my $list1 = shift;
    my $list2 = \@_;
    my @results;
    for my $i(0..$#$list1) {
        local $a = $list1->[$i];
        local $b = $list2->[$i];
        push @results, &$cl;
    }
    return @results;
}

So, to do a hyper-add on two lists with that, "dmap { $a + $b } @foo, @bar". Without the prototype, that would have to have been written as the uglier "dmap sub { $a + $b }, \@foo, @bar"

Update: Changed $#list1 to $#$list1. Thanks sauoq.

--MrNobo1024
s]]HrLfbfe|EbBibmv]e|s}w}ciZx^RYhL}e^print

[sauoq]

So, to do a hyper-add on two lists with that, "dmap { $a + $b } @foo, @bar". Without the prototype, that would have to have been written as the uglier "dmap sub { $a + $b }, \@foo, @bar"

If you wanted to use a literal list or the output of another sub as the second argument to dmap() as it is written in your node, you'd have to resort to dereferencing anonymous arrayrefs such as: @{[ your_sub_or_list_here ]} and that's just as ugly if not more so. The other choice would be to circumvent the "prototype" by calling it as &dmap( ... ) instead.

It might be "uglier" for some calls, but by writing it without the prototype, you encourage consistency which translates to cleaner code overall.

-sauoq
"My two cents aren't worth a dime.";