I apologize for not including a previous message thread -- I
fumble-fingered myself out of all the relevant ones....
Still, I'd just like to cast my tiny vote regarding inferences.
I'd like to be able to write classes that can take advantage of
screaming speed, and types contribute.
I'd like to be able to tell my main script that it is required to pass
exact types, so that it gets those advantages. (I'd like something like
"use strict;" without specifying "strict what" to default to "strict
everything".)
I'd still like to be able to use my module in quick one-off's without
having it break and die if I just pass it whatever default variable I
can manage not to declare.
Wouldn't I be able to do that by writing my module with something like
multi foo (Int $i) {...}
multi foo (Scalar $s) {...}
???
Yes, I realize most people don't want to write seven versions of every
sub; but most of the time, my module is either going to be generic
enough that I'm not really as interested in the screaming end of speed,
or specific enough that I don't expect to use it for many one-off's, or
worth a little extra code.
Still, as a best-case, I'd like for the strict()-ness of my main
program to drive the determinance. If it's a slopjob quickie, I don't
*CARE* about greatspeed. Just DWIM and gimme what I want. If I want
fast code it's worth being careful, so I'll use strict and expect it to
gripe and expire if I didn't do something quite right.
So, my vote is, do the run-time checking if not strict; restrict me to
compile-time compliance under the strict pragma.
To be honest, I'd also kinda like to see a coerce-it-if-you-can
behavior, but I'd rather have that as a pragma as well. If it's worth
all the extra work to find an appropriate coersion, it's worth a few
extra keystrokes..... but I could live without all that quite happily.
Am I off base?
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
