Sam Ruby <[EMAIL PROTECTED]> wrote: > Leopold Toetsch wrote: >> >> "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. ... a bit by the lack of progress that can be achieved to e.g. fix broken continuation behavior. But not much ;) > ... 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. Well, you worried about different classes having identical method names, but the methods do different things. I asked why this is a problem. I gave an example. Here is one more: obj."__set_integer_native"(10) does 2 totally different things for arrays (set array size) or for scalars (assign value 10). > Re: VTABLES... I disagree with you on this one. Prematurely mapping an > operation to a string is a premature pessimization. Except that we are doing that already. Please read through classes/delegate.c. The problem is that this scheme doesn't work for MMD of real objects. > ... Add to that the > fact that such names can conflict with usages by languages of this > runtime. Parrots method names (two leading underscores + vtable name) are reserved. And again, when two distinct clases use the same method name this is no conflict at all. Issues with classes in an inheritance chain are easily avoided by following that convention. > ... Overall, the design of the opcodes and PMC layout should focus > on trying to retain as much information as possible. Nothing get lost. Visible opcodes don't change. An example .sub m $P0 = newclass "Foo" $I0 = find_type "Foo" .local pmc obj obj = new $I0 obj = 5 .end running that snippet gives: Can't find method '__set_integer_native' for object 'Foo'. The vtable method set_integer_native clearly maps to a real method that can be either inherited or be provided by the user. This doesn't work for MMD functions. > 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. No. I'm not ditching lexical pads at all. They are of course needed. The top pad is in the registers. Outer pads are looked up as usual. > - Sam Ruby leo
