Damian Conway:
# a) The argument passed here must be something that
# could conceivably
# not cause the program to crash and burn, and
# we'll verify that at
# run-time if necessary.
#
# or:
#
# b) The argument passed here must be something that will
# definitely
# not cause the program to crash and burn, and
# we'll verify that at
# compile-time.
#
# I'm arguing that the former is well-nigh useless, and that
# the latter is what
# large systems developers and optimizer writers have been
# begging for. Besides
# which, the latter gives you the former. If you don't care
# about compile-time
# type checking, declare the *parameter* as Scalar, and let it
# accept anything.
IMO, the semantics should be something like this:
Assume F is the type of the formal parameter and A is the type
of the actual parameter.
If A isa F, we're fine.
If F isa A, defer type checking to runtime.
Else, pitch a fit.
Since the default type is Object and any type isa Object, untyped formal
parameters are "checked" at compile time and untyped actual parameters
are checked at runtime.
That's the semantics for strict typing, anyway...
# But if type-specialized parameters are allowed to take
# *anything*, then
# they're nigh on worthless, except as a (third) coercion
# mechanism (in addition
# to explicit int($x), +$x, ~$x; and implicit contextual coercions).
What's wrong with that? It gives us a way to ensure that we have a
suitable object without having to remember to check ourselves.
I think that there should be two types of arg typing[1]: 'strict' and
'loose'. Strict arg typing doesn't coerce, except to turn subclasses
into superclasses; loose arg typing, on the other hand, coerces whenever
possible. The mechanism for choosing between strict and loose arg
typing should be under the caller's control, not the callee's. (The
callee decides what types they want, and the caller decides how to
create those types. This seems consistent with Perl's philosophy of
being flexible and making B&D optional.)
Strict arg typing should be under the control of the 'strict' pragma,
and should be in strict's default export list. This would mean that the
B&D would be off by default but easy to turn on.
[1] Perhaps this should be generalized to strict and loose coercion; I'm
not really sure yet. (Under strict coercion, adding an Int and a Str
would be an error, instead of coercing the Str into an Int.)
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>How do you "test" this 'God' to "prove" it is who it says it is?
"If you're God, you know exactly what it would take to convince me. Do
that."
--Marc Fleury on alt.atheism
