"correct". I've discovered and analysed the problem with continuations. I've made a proposal to fix that. No one has said that it's technically wrong or couldn't work. It seems you are liking the idea, but Dan doesn't. Now what?
I would suggest focusing on one issue at a time and starting with writing a test case.
But, overall, it is clear that you are frustrated. It show when you give responses like "Doesn't really matter" when people like me ask questions about your proposals. That, in turn, makes people like me frustrated.
Re: classoffset... I don't currently use this opcode, nor do I plan to. This opcode has a builtin assumption that attributes are stored as attributes. They may in fact be methods or properties in the Parrot sense, or Property's in the Python sense.
Re: VTABLES... I disagree with you on this one. Prematurely mapping an operation to a string is a premature pessimization. Add to that the fact that such names can conflict with usages by languages of this runtime. Overall, the design of the opcodes and PMC layout should focus on trying to retain as much information as possible.
Re: continuations... frankly, I'm hoping that a solution emerges that doesn't involve significant reduction in functionallity. I might be misunderstanding you, but it sounds to me like you are proposing ditching lexical pads.
- Sam Ruby
