On Sunday 02 September 2001 07:49 pm, Dan Sugalski wrote:
> On Sun, 2 Sep 2001, Bryan C. Warnock wrote:
> > Are prototypes going to be checked at runtime now?
>
> For methods, at least. Dunno about subs, that's Larry's call. I could make
> a good language case for and against it. It adds overhead on sub calls,
> which is a bad thing generally. (I'd be OK with the declaration "All
> prototyped subs must have their prototypes known before the BEGIN phase is
> done"... :)
Well, here's a simple, yet stupid, idea. (And I'd be content with having
prototype declarations being a compile-time only requirement, too.)
Code injection, a la Perl's -p and -n switch.
sub foo (protoype) {
code
}
is compiled as
sub foo { {
my $proto = prototype;
# prototype checking code here. Must be non-destructive on @_
}
code
}
- It only affects the specific subroutines that declared prototypes in the
first place.
- With the ability to inject lexical variables up a scope, prototype
assignment would work...
sub foo (my $bar, my Dog $baz, my @array) {
# $bar, $baz, and @array are all visible
}
- It's certainly pluggable. It could even be written in Perl. That means
powerful prototyping capabilities.
- Automagically works with named subs and code references, subroutine
replacement a la 'goto &cref', and any other way you could think of calling
the subroutine.
- If the subroutine is ever replaced, the prototypes magically go away. (Or
are replaced by ones in the new code.)
- It could be standard enough (from an opcode generation perspective, that
B::Deparse would be able to reconstruct the original subroutine code.
--
Bryan C. Warnock
[EMAIL PROTECTED]
