knexus has asked for the
wisdom of the Perl Monks concerning the following question:
I don't know if this is a big issue or not.
Anyhow, I am questioning the use of prototypes and perhaps my understanding of their purpose in perl. After reading a little on the subject and considering some things mentioned here, I am just uncertain if I should use them or not.
In other programming experience I had developed the opinion that protypes were a good thing as they provide usage enforcement. Plus IMHO a list of subs with their parameters at the beginning of a file gives me a quick insight, i.e. aiding the understanding of the program or module.
However, if I understand what it being said in this post then I'd think twice about using prototypes if performance is at issue.
Any guidance here would be appreciated.
I apologize in advance if I have completely misunderstood.
Thanks
Edited link to PM canonical form at author's req. - dvergin 2003-08-31
Re: Prototyping Subs: Good,Bad,Indifferent by liz (Monsignor) on Aug 31, 2003 at 17:19 UTC |
I hardly ever use prototypes. Why? Because I mainly program with modules and objects. And prototypes are useless with method calls, as the subroutine handling the method call is determined at run-time. And prototype checks occur at compile time. So if you're into OO programming, don't worry about prototypes (at least not in Perl 5 ;-)
The only use I've had for a prototype in my career, was with the share() subroutine in my forks module. That subroutine should be passed a single scalar, array or hash, but receive the appropriate reference as the parameter (without flattening). Take this example:
sub foo (\[$@%]) { print "received a $_[0]\n" }
foo( $a );
foo( @a );
foo( %a );
will print something like:
received a SCALAR(0x107c84)
received a ARRAY(0x107d44)
received a HASH(0x107d68)
Without the prototype this wouldn't work at all. I guess this was one of the neat features added in 5.8.0.
On the other hand, I know of people who use prototypes on subroutines that are intended to be called as methods purely for the documentational value.
Hope this helps.
Liz | [reply] [d/l] [select] |
Re: Prototyping Subs: Good,Bad,Indifferent by blokhead (Monsignor) on Aug 31, 2003 at 17:43 UTC |
Have you read FMTYEWTK about Prototypes by Tom Christiansen yet? It's the reference for everything that's wrong/annoying/misunderstood about Perl's prototypes.
In other programming experience I had developed the opinion that protypes were a good thing as they provide usage enforcement
Prototypes in Perl are not analagous to prototypes in other languages. Calling them "prototypes" is a bit of a misnomer. But Tom Christiansen describes this better than I can.
I know many monks, myself included, only use prototypes to get subs to look like builtins, especially passing a bare block as the first argument (as in grep { ... }) or an array ref (as in splice @arr). They're ok occasionally for this kind of syntactic sugar, but they're not as useful as you'd think for actually enforcing parameters. As I said, read that article if you haven't read it yet, otherwise read it again ;)
blokhead | [reply] |
|
That article really helps.
I certainly was NOT accomplishing what I thought.
Thanks
| [reply] |
Re: Prototyping Subs: Good,Bad,Indifferent by lestrrat (Deacon) on Aug 31, 2003 at 17:48 UTC |
Here's something to read: Far More Than Everything You've Ever Wanted to Know about
Prototypes in Perl.
I try not to use it in Perl partly because it gives you the false impression of security. While it enforces certain context/number of arguments, for some reason a lot of people I know tend to not validate their input if you have a function prototype. Which is really bad, especially when you try to make the transition from procedural to OO Perl, where no prototype check is done.
Plus it's really damn annoying when something like this compiles:
sub foo($) {
...
}
foo(@bar); # = foo( scalar( @bar ) ). argh.
I'd rather stick with Params::Validate | [reply] [d/l] |
Re: Prototyping Subs: Good,Bad,Indifferent by jeffa (Chancellor) on Aug 31, 2003 at 17:53 UTC |
The only time i have seen prototypes actually being
recognized is with mod_perl. In
mod_perl, you can prototype your handlers:
sub handler ($$) {
my ($self,$r);
# yadda yadda
}
This tells mod_perl that your handler is really a
method handler, and in return, mod_perl will hand
you "both the handler() method's calling class and
the Apache request object." (from the
mod_perl Developer's Cookbook).
But other than that, i never use prototypes.
jeffa
L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
| [reply] [d/l] |
|
| [reply] |
Re: Prototyping Subs: Good,Bad,Indifferent by Abigail-II (Bishop) on Aug 31, 2003 at 23:19 UTC |
In other programming experience I had developed the opinion that protypes were a good thing as they provide usage enforcement.
That may work for other languages, but forcing a programmer
to jump to certain hoops isn't very Perlish. If you prefer
bondage programming (and I don't mean this negatively, in
fact, I think most people, and that includes most people
currently programming Perl, are better off using a bondage
language instead of Perl), you shouldn't use Perl, but say,
Java or Python.
Having said that, the only times I use prototypes is to
change how function calls are being parsed. So, I use it
to create function that take blocks are arguments, or to
create unary functions. Or to autoreference arrays and
hashes.
Abigail
| [reply] |
Re: Prototyping Subs: Good,Bad,Indifferent by tachyon (Chancellor) on Sep 01, 2003 at 01:05 UTC |
This is about the only way I ever use them - to get a function that does not need parens and behaves like an inbuilt
sub strip($);
my $str = '
begone
leading
whitespace
';
print strip $str, " ->this is extra stuff";
sub strip ($) {
my $str = shift;
$str =~ s/^\s+//gm;
$str;
}
cheers
tachyon
s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print
| [reply] [d/l] |
Re: Prototyping Subs: Good,Bad,Indifferent by demerphq (Chancellor) on Sep 01, 2003 at 09:53 UTC |
| [reply] [d/l] |
|
|