The other advantage of typed languages is that the run-time can
be faster, and the storage streamlined.
> There is a drawback: exceptions raised ("That's not an integer!" *croak*)
> are made at run-time, rather than compile-time (as would be more useful).
> As a result you have to test all code paths if you are to use this as any
> sort of internal sanity checking; I assume most everyone does this, but it
> would be useful for it to be a compile-time check, so that perl -c would
> catch all of your errors. This could possibly be accomplished by allowing
> arguments to the pragma or variable initialization.
>
> use typing qw(very-strict);
> my integer $foo : very-strict = 4;
>
> Which would enforce that you can only assign integer constants to $foo
> (which are seen at compile-time), or other similarly declared integers (or
> possibly promoted floats, chars, etc. if you wanted to get C-like). This,
> then, could allow you to do checking at compile-time.
Typed things would only be able to accept data from things with compatbile
types, or declared impliable conversions. Strict could force the conversion
methods to be selected at compile time, with
use strict typeconversions
> Which then raises a few more problems (whew): how do you coax user input
> (which is an SV) into a value $foo can accept with very-strict on?
You run it through an explicit conversion process, like using C<atoi()> in
a C program
>; what
> happens when an external function (say, from a module) is being very-strict,
> but is passed arguments from code that doesn't do type checking?
This is documented in the module's documentation, so (I say this at the risk
of bringing on the wrath of those who hate C++ casting) a conversion method must
be called.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq On hold for tech support since midnight
