Sam Ruby <[EMAIL PROTECTED]> wrote: > I continue to disagree with the part of this conclusion where you insert > find_method into the discussion. To give a concrete example: at the > moment the lookup involved in abs_p_p does not involve the use of > find_method.
$ cat abs.imc .sub main .local pmc cl, o cl = newclass "A" $I0 = typeof cl o = new $I0 $P0 = new Undef $P0 = abs o print $P0 .end .namespace ["A"] .sub __absolute .param pmc d d = "ok\n" .end $ parrot abs.imc ok $ parrot -t abs.imc ... # find_method class 'A' method '__absolute': Sub # Calling sub '__absolute' ... > ... Nor does the lookup involved in find_method_p_p_s for that > matter. ??? > If Perl programmers need to know about Parrot method names, then > effectively this beomes part of the Perl language specification. I do > not have the luxury of changing the Python language specification. If you are targeting Parrot you have to know the opcode names *and* the reserved method names, sorry. > I continue to push for the "namespace" for Parrot internal dispatching > and language level method names to be disjoint. That's a different thing that we can consider. > ... If Python metaclasses > get surprising results if they happen to define a method named > "instantiate", expect a bug report. Ok. The call syntax should rather be "__instantiate" to be consistent. > ... (BTW, a combined instantiate method > does not map well to Python which has separate __new__ and __init__ > methods. We have the "__init" hook too. This is separate. $ parrot -t abs.imc ... 6 new P17, I30 - P17=PMCNULL, I30=72 # find_method class 'A' method '__init': no > ... My recommendation > is to stick to primitives, and simply provide a new_p_p). What is the second "_p" for? > There needs to be separate "find_method" operations for external (i.e., > visible at the language level) names and Parrot internal names. Maybe. But why is it necessary? > That is only because the design you have in mind conflates Parrot and > language operations. There is no reason that __abs__ couldn't call > VTABLE_abs, or that __add__ can't make use of MMD_ADD. And if the class implements it's own "__absolute" or "__add", we do a separate redispatch? And dynclasses/py* does it differently to dynclasses/perl*. Why don't you just believe me that that's error prone and slow ;-) > - Sam Ruby leo