Single-inheritance objects seem to be done. The code can use a lot of abuse and cleanup, and we need actual tests to make sure that it functions as it should, but they're in.
Here's the technical scoop.
When you create a ParrotClass-based class (which is to say, you use the class creation ops that we provide) you get a class PMC that's got all the class information hanging off it. This stuff's documented at the top of classes/parrotclass.pmc though better docs are definitely in order.
Since creating the class is handled by the code in objects.c rather than in the class vtable, we get to play a number of games:
Games we play:
==============
*) The class code knows its dealing with parrot classes (there's a flag to tell us) and it cheats. Not too badly, but some. Probably should cheat more, but I'm up for getting it working before doing Horribly Evil Things.
*) Creating new objects involves calling the ->init vtable entry *on the class*. Because of this each class gets a custom vtable where the init method has been swapped out for one (from objects.c) that creates a new object instead.
But it seems to work out. Slowly (no method cache definitely hurts) but still, works is good. The PMC that the class ->init method hands back is a ParrotObject, rather than a ParrotClass, which is good as it's an object and all. The vtable on the object is currently the base ParrotObject vtable which, as you can probably see, doesn't do a whole lot besides method calls.
Still to do: ============ *) Multiple inheritance *) Runtime inheritance changes *) Runtime attribute changes *) Metadata support for class creation *) Tests to make sure it actually, y'know, works. *) Delegation of vtable methods to methods in the class *) fallback method finding
Happy "Abuse the Objects" day, everyone. :)
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
