At 09:57 PM 11/3/2001 -0500, Brian Wheeler wrote:
>On Sat, 2001-11-03 at 21:40, Gregor N. Purdy wrote:
> >
> > None of these are issues with the approach I've been working on /
> > advocating. I'm hoping we can avoid these altogether.
> >
>
>
>I think this is a cool concept, but it seems like a lot of overhead with
>the string lookups.
For the core opcode set, the one shipped with perl, we absolutely must keep
those numbers constant. There's no real good reason for them to change, and
if they're constant we don't have to worry about fixing things up at
runtime. That's a cost we then don't have to pay every time we load a
compiled program up. (We have to pay it at compilation time regardless, of
course, but no reason to pay it more than once)
Libraries loaded from disk are a separate matter entirely. I'm tempted to
require that the exported opcodes stay in the same order for the lifetime
of the library, but that pushes good version and export control off to the
developer community as a whole. Building an export list that gets packaged
up with modules isn't that tough, but I worry that people won't do it.
So I suppose we have three sorts of opcode libraries:
1) The core set. These must have constant numbers that don't change over
the life of perl.
2) The core library set. These will have reserved sets of opcode numbers
and shouldn't change either. (Stuff like the socket library, for example)
We load 'em at runtime, though
3) User libraries. These we should have some method of cherry-picking the
functions we want, and we won't count on the numbers for the opcodes in the
library. Also loaded at runtime.
I really, *really* want to require that the export list for a module be
constant, but I'm not sure we can get away with that safely.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
