Sam Ruby <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch wrote:
> So *all* lookups (complete with the asterisks) does not mean *all* lookups.
> How about <invoke>?
Let's first concentrate on simpler stuff like infix operators.
>> Citing S06: "Operators are just subroutines with special names."
> That statement is true for Perl. Same statement is true for Python.
> But the names vary based on the language.
Yes. So let's factor out the common part and have that in Parrot core,
usable for Python and Perl and ...
The PyInt PMC currently duplicates almost all functionality that
*should* be in the Integer PMC. We have first to fix the Integer PMC to
do the Right Thing. Then we need some syntax for multiple inheritance in
PMCs. The same holds for other PMCs. It was already proposed that we
should have a language-neutral Hash PMC.
So given that we have a set of language-neutral PMCs in core that do the
right thing, Python or Perl PMCs can inherit a lot of functionality from
core PMCs. Language-specific behavior is of course implemented in the
specific PMC.
Second: method dispatch. I've looked a bit into PyObject. It seems that
you start rolling your own method dispatch. Please don't get me wrong,
I'm not criticizing your implementation. It might also be needed for
some reasons I'm just overlooking and it's currently needed because core
functionality isn't totally finished.
Anyway - and please correct me if my assumptions are not true - I'll try
to factor out the common part again.
You have in PyObject e.g.:
METHOD PMC* __add__(PMC *value) {
PMC * ret = pmc_new(INTERP, dynclass_PyObject);
mmd_dispatch_v_ppp(INTERP, SELF, value, ret, MMD_ADD);
return ret;
}
I see six issues with that kind of approach:
* The "__add" method should be in Parrot core. That's what I've
described in the MMD dispatch proposal.
* the method is returning a new PMC. This doesn't follow the signature
of Parrot infix MMD operations.
* well, it's dispatching twice. First the "__add__" method for
PyObjects has to be searched for then the mmd_dispatch is done.
* it'll very likely not work together with other HLLs. It's a
python-only solution.
* rolling your own dispatch still doesn't help, if a metaclass
overloads the C<+> operation
* code duplication
So how would I do it:
* prelim: above mentioned core PMC cleanup is done. Inheritance works:
a PyInt isa(PyObject, Integer)
* the core PMCs define methods, like your "__add__" except that our
naming conventions is "__add". The Python translator needs just
a translation table for the common core methods.
* Method dispatch is done at the opcode level.
add Px, Py, Pz
just does the right thing. It calls the thingy that implements the
"__add" method, being in core or overloaded shouldn't and doesn't
matter. If inheritance changes at runtime it just works.
And the other way round:
Py."__add"(Pz, Px)
is the same. Again it doesn't matter, if it's a core PMC, a Python
PMC or an overloaded PASM/PIR multi sub (or a Python metaclass).
The only difference is the changed signature. But that's how Parrot
core defines overloaded infix operations.
We have to do that anyway. It's just the correct way to go.
(And please no answers WRT efficiency ;-)
leo
