Read just enough to recognize them when you see em. Prototypes are one of the corners of Perl that tend to be left unused for the most part because they tend toward surprising behavior.
Perl is environmentally friendly - it saves trees
| [reply] |
There seems to be a lot of negative commentary on function prototypes through the monastery archives. However, I haven't seen anything that looks like a definitive reason to consider them 'wrong', or a 'failed experiment'. Coming from a C++ background, I've used them religiously since I started coding Perl, and have always found them to work exactly as I expect them to (and as documented). Prototyping (along with use strict, of course) has kept me from having much weirder problems to diagnose than mismatched argument lists.
I'll admit that Perl's function prototypes are kind of weird; but obviously, if you took all the weirdness out of Perl, it would be C, and what would be the fun of that?
There seem to be examples of some problems with what I'd consider bizarre argument lists (particularly with function refs). I haven't ventured into doing such things. For 'normal' scalars, arrays, array refs, hash refs, etc. prototypes work just fine.
Another thread of complaints was this node, but for some reason the author thought that declaring a sub as taking one scalar should accept a list anyway. Whatever. perl.com supposedly has an article that explains it all, but the link isn't working.
Could I get an example of where a function prototype is clearly broken so bad that illustrates why they need to be avoided?
/me is expecting to wind up demoted for daring to post a controversial opinion.
| [reply] |
Re: Are prototypes evil? has a pretty good explanation (as well as the discussion to same author's When to use Prototypes?). You can't reliably use prototypes for argument validation since that's not what they do; they only coerce the context the value is placed in. sub foo ($) doesn't mean that you can only call foo( $scalar ), but that whatever argument you do pass will be put in scalar context. That means that foo( bar() ) for some bar which is context sensitive isn't going to do what you expect unless you're intimately familiar with foo's prototype. No errors will be raised, no warnings will be generated, but the behavior will be different than the norm.
Or another example: given sub baz ($$$) and my @a = qw( a b c ), you can't just call baz( @a ) you have to explicitly write baz( $a[0], $a[1], $a[2] ). There's 3 arguments available, it may make perfect sense to keep them grouped in an array, but because of the prototype you've got to go through extra hoops and write more code.
This is why the conventional wisdom is to avoid them unless you're explicitly trying to mimic a builtin. If you want argument validation, there's better ways to do so.
The cake is a lie.
The cake is a lie.
The cake is a lie.
| [reply]
[d/l]
[select] |
Fletch's node gives links to a couple of excellent threads discussing the core problems. Just for the sake of comfort though: I too spend most of my day writing C++ and I also started out thinking prototypes were some sort of compile time argument checking (they aren't - that's the problem) so used them everywhere. Probably it was exactly some such thread as this that dissuaded me, along with a bunch of other C++ism that were apparent in my early Perl. I think I've exorcised most of them now. ;-)
Oh, and controversial comments don't get you demoted here. Continuing to use prototypes may though - in RL when you get bit by a subtle bug due to them.
Perl is environmentally friendly - it saves trees
| [reply] |