Leopold Toetsch wrote:
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' ...
But only for classes that inherit from delegate.
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.
People writing Python to Parrot translators need to know Parrot internals. People who merely write in Python should not.
... (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.
Ultimately, I believe that this will need to be revisited.
$ 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?
What I am thinking of is something like:
inline op new(out PMC) {
$1 = VTABLE_instantiate(interpreter, $2);
goto NEXT();
}Where instantiate does not support a variable number of arguments (Parrot calling conventions). If you then want to init the PMC you have obtained, you can use the separate init hook (with a variable number of arguments).
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 ;-)
Only in the sense that CoRoutine and RetContinuation provide "incompatible" (i.e., different) implementations of invoke. However, they are very compatible in the only sense that matters: they both implement the common protocol named "invoke".
Arguably, the very reason that a find_method VTABLE entry was provided was to enable different PMCs to provide different implementations of this protocol.
The code that backs perl classes can have implementations find_method that looks for __add methods with a given parameter signature, and the code that backs python classes can have implementations of find_metho that looks for __add__ methods with a different parameter signature.
- Sam Ruby
