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
