Sam Ruby <[EMAIL PROTECTED]> wrote:
Dan Sugalski wrote:
[ method lookup ]
Parrot_CompositeObject_find_method should do that. object.c should not.
I think, when going down the class hierarchy, we just have to call class->vtable->find_method() again, istead of the Parrot_find_global.
If "we" is Parrot_CompositeObject_find_method, then I'm quite OK with that. If "we" is Parrot_default_find_method, then I'm fine too. However, if "we" is src/object.c, then let's talk some more.
And, yes, the PMC's for all the "core" and "dynclass" are indexed for convenient access. But, in any case, there should be a "new_p_p" opcode which should do a $1=$2->vtable->instantiate(interpreter);
That is exactly what is currently PObj = Pclass->vtable->new_extended().
Cool!
All objects also must be able to perform the method:
get_anonymous_subclass - to put the object into a singleton anonymous subclass
Sorry, you lost me here.
A singleton object is the sole instantiation of a class. You'll always get that one object.
I know what a singleton is. I don't know what it means to "put the object into a singleton anonymous subclass", or why you would want to do such a thing.
Yes, MMD is the big elephant in the room. A commit later today will create a PyComplex and PyLong that (for the moment) is a wholesale clone of Complex and BigInt respectively simply because I wanted to override a few methods and couldn't figure out how to get MMD to behave the way I wanted. Obviously, this will need to be refactored later.
We need multiple inheritance for PMCs. A PyComplex isa(PyObject, Complex) PMC. There is minimal support for that - used in the OrderedHash PMC. But the PMC compiler should be more clever:
void add(...) { MMD_PyComplex: { Complex.SELF.add(...); }
should install the MMD subroutine for the complex PMC Parrot_Complex_add_Complex()
Even if that were done, that would only handle cases where PyComplex were the first argument. In general, it would be nice if there were a way to express "for purposes of MMD this class is a Complex".
- Sam Ruby
