Ok, I've realized a few things.
1) There's two sorts of type-checking going on here. Compile-time and
run-time.
2) Run-time type checking is fairly easy and imposes few limitations. In
fact, you can even do it now through ad hockery.
3) Compile-time type checking is a bit harder. Any module/class which
wishes to be compile-time checked must not have its *signature*
altered at run-time.
By "signature" I mean the methods, functions, global variables and
inheritence tree of a strict class must be defined at compile time.
All the external stuff. The internals can change at any time.
This means you can still AUTOLOAD, so long as the function signature
is defined beforehand. But you can't use AUTOLOAD to define brand new
methods of the strict class.
eval STRING still works, just so long as it doesn't modify a strict
class. It can call methods of a strict class, and this is all checked
at the eval's compile-time.
Dynamic method calls ($obj->$method()) works, it will be run-time
checked. Subroutine refs, same thing.
Symbol table manipulation will work as long as your mucking about
doesn't alter the strict class's signature. ie. you can shove a code
ref onto the symbol table as long as a stub for that method was
defined at compile time.
Automatic method generation will work, but only for those known at
compile-time. Which is fine.
So mod_perl, Apache::Registry, AutoLoader, Class::Accessor, Exporter,
Template Toolkit can all still work, with a bit of reworking.
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
My feet hurt... with destiny!
http://sluggy.com/d/010204.html
