Perl6 RFC Librarian writes:
> I therefore propose that C<my Dog $spot> comes to mean that C<$spot>
> is restricted to being either undefined or a reference to a C<Dog>
> object (or any subclasses of Dog). Simply having this implicit
> assertion can be useful to the programmer, but I would argue that its
> main advantage is that the compiler knows the object's interface at
> compile time and can potentially use this fact to speed up method
> dispatch.
Yes! I mentioned the hypothetical
use strict 'types';
which would require all variables assigned to/from an object, and
all variables upon which method calls are made, to be typed like
this. Then the compiler can:
(a) optimize
(b) check at compile-time
Your sample implementation is done through a Tie class, which is only
runtime. The big win is that if you check types like this (and it's
a window into C's type-checking hell) then Perl knows types at
compile-time. If there's a formal interface specification for classes,
the compiler can use this to check whether a method call is valid or
not. You can build calls to the correct subroutine into optree
instead of delaying that lookup until runtime.
Every compile-time check comes at the cost of a run-time freedom,
though. All bets would be off if you modified @ISA, reblessed, or
passed objects through non-strict-types-compliant code. Polymorphic
types also becomes a problem: how to say that it's okay for a variable
to hold a Dog *or* a Cat, because we know that both of them have a
"pet()" method?
I'd love to see these suggestions incorporated into your RFC. I was
going to do it myself, but I have a lot of other things to RFC.
> =head1 MIGRATION
>
> Migration issues should be minor, the only problem arising when people
> have assigned things that aren't objects of the appropriate type to
> typed variables, but they deserve to lose anyway.
Not if you made the checks and optimizations enabled by a pragma.
Old programs wouldn't have it, so they could continue to do their
stupid things and be fine.
Nat
