--- Paolo Molaro <[EMAIL PROTECTED]> wrote:
[snip, snip]
> The problem here is to make sure we really need the
> opcode swap
> functionality, it's really something that is going to
> kill
> dispatch performance.
> If a module wants to change the meaning of, eg the +
> operator,
> it can simply request the compiler to insert a call to a
> subroutine, instead of changing the meaning assigned to
> the
> VM opcode. The compiler is free to inline the sub, of
> course,
> just don't cripple the normal case with unnecessary
> overhead
> and let the special case pay the price of flexibility.
> Of course, if the special case is not so special, a _new_
> opcode can be introduced, but there is really no reason
> to
> change the meaning of an opcode on the fly, IMHO.
> Comment, or flame, away.
Unfortunately, compiler tricks only work at compile time.
They're great for static languages like C++ or C#, but Perl
supports doing
%CORE::GLOBAL::{'&print'} = \&myprint;
at _runtime_. This is much to late to be going back and
patching up any occurences of print_p in the opstream, so
we need a level of indirection on every overridable opcode.
(Note that the _overloadable_ ones like the math routines
don't need that level of indirection - they get it by
vectoring through the PMC vtables).
-- BKS
__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
