James deBoer <[EMAIL PROTECTED]> wrote: > Ok. If we are moving things like split into objects at some point in the > future, should the split opcode be removed now?
This again goes into: what's an opcode. There are two views: - surface: i.e. what the assembler understands - in core: what the runcore executes, that is what the assembler did do with the opcode > (I'm guessing the answer is yes, since split is one of the opcodes > listed in your 'Too many opcodes' post of a few weeks back) So while the split opcode syntax in PASM/PIR can remain I'm pretty sure that the runcore will get a method call, which also means that a HLL compiler can emit that method call directly because they are the same. > At this point the split opcode doesn't really do anything useful, and > any fixes/improvements to it would be lost when the logic is moved to > String/PerlString/PythonString/... objects. But, as the current syntax doesn't provide the needed functionality we could change it now into: Px."__split"(...) # a method call or we change the opcode to be: =item B<split>(out PMC, in PMC, in STR) where $2 is the class that "can split", e.g. String or PGE and do a method call in the split opcode. > - James leo
