This is similar to the solution they use in Java.  You have an interface,
which is compile time checked.  Then, when you load a class at runtime, you
check at load time that it satisfies the interface.  You either get an
exception right then, or you're fine.

Daniel


Michael G Schwern wrote:

> 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

Reply via email to