Nathan Torkington <[EMAIL PROTECTED]> writes:
> 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.
TBH, I'm not sure I want to go too far down that road in this RFC. And
tbh they seem more like internals issues to me. The runtime behaviour
this change grants is good enough for me and I don't want to see the
proposal bogged down in flamage about strict types. Of course, given
this RFC it's possible to add other RFCs that deal with specific
dependent language proposals and optimizations.
> > =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.
Again, I'm not sure that I'd want to encourage such bogosity. After
all, if perl5 could introduce "@array" interpolation which broke stuff
I don't see why this one can't go through as the default.
--
Piers
