RFC: Prototyping, do or don't?

2004-01-13 Thread Dan Anderson
I am somewhat confused as to when to prototype a subroutine.  Under the
tips section Programming Perl makes the following points:

1.  Prototyping can lead to inlined functions which increases the speed
of commonly used functions.  Prototype when you can.
2.  As soon as somebody uses your function in a way it wasn't supposed
to be used, your program can explode.  Never prototype.

(This is not verbatim -- but it's the same general idea)

Can anyone go more in depth about the pros and cons of prototyping?

Thanks in advance,

Dan



-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response




Anti-Prototyping - Re: RFC: Prototyping, do or don't?

2004-01-13 Thread drieux
On Jan 13, 2004, at 6:59 AM, Dan Anderson wrote:
[..]
	1.  Prototyping can lead to inlined functions which increases the 
speed
of commonly used functions.  Prototype when you can.
	2.  As soon as somebody uses your function in a way it wasn't supposed
to be used, your program can explode.  Never prototype.

(This is not verbatim -- but it's the same general idea)

Can anyone go more in depth about the pros and cons of prototyping?
[..]

I remember going back to myUnterStumpenFumbler and asking
him this very question - since I took some time to prototype
a few things - since it looked like it was a cooler idea -
you know make my perl modules look more like ANSI C, or
Java, or Lions  Tigers  Bears...
I hate to come out so strongly against prototyping,
but let's look at the 'virtue' side - it might increase
some of the speed - but if speed were the issue, then
why are we using a jitc language where we have a ref count
memory model
This then gets us into the minor technical problem that
perl is a list muncher
	my @got_back = function(@arglist);

so the effort to provide some sort of 'signature' where
we can say
	sub function($$$) { ... }

is great for requiring that they be scalars - but it
does not really resolve 'scalars of what' as it were.
The Prototype there is not going to be able to
resolve that problem for you. That will
still need to be checked in the function... so that
one knows that the three scalars on @_ are scalars
of the type that you really wanted, and not, well
a plain scalar, an array ref, or an object ref
{ yes, I know there are some ways to be a bit more
clearer that one wanted a FooRef for basic perl primatives }
So while the compiler will be able to protect you from
some stoopids, it will not protect you from the fact that
perl is not a strongly typed language where the Compiler
will protect you from all Evil! That is it's Strength!
Prototyping was an effort to try to do some of the context
clarification to try to bring a bit of strong arming to
the process...
So it's one of those, well, misadventures that is a
part of the Perl Legacy.
If you need to have your coding language be in BDSM,
then you can start with prototyping, then get really
in touch with croak and caller, and make absolutely
certain that anyone using your module in a way not
expressly asserted in your POD knows for 100% certain
that it was their fault - go for it...
Otherwise, accept that in the long run it is simpler
to skip over the prototyping
ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/ http://learn.perl.org/first-response