--- Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 12:11 PM 8/2/00 +0100, Tim Bunce wrote: > >Thinking about that some more, I can imagine that... > > > >a) The 'use' of an 'interface definition' could > optionally just define > > stubs that will trigger the 'use' of a module to > implement it when > > first called. > > > >b) An 'interface definition' could cover multiple > modules > > (or, more strictly, multiple interface definitions > for those modules). > > Thus a single 'use' of an 'interface definition' > thingy could save > > many lines of individual 'use' statements. > > Yup, that pretty much summarizes things. I'm thinking of > some sort of list > of functions (pre-munched appropriately, so the lexer has > fast access to > it) with attached prototypes and shared library routine > names. You use, > say, localtime and perl automagically loads in > perl_localtime.so. > > I wanted to do this not so much to reduce the size of the > core (They're not > *that* much code) as to reduce the number of opcodes > being used. I really, > *really* want to trim down the opcode list. Hear, hear! However, one thing I would like to see is the removal of some ov the horrible polymorphism imposed on some of the opcodes. I understand that opcodes may need to do different things depending on their context or argument types, but there really isn't much of an excuse (that I know of, correct me if I'm wrong) for pp_readline to be supporting OP_READLINE and *OP_GLOB*! Doing so reduces code legibility, and imposes unneeded bloat (and cache misses) on verious pp functions. -- BKS __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/
