The issue is metadata. How do you declare a class' inheritance hierarchy, its interfaces, its attributes, and its type? (At the very least, there's probably more) I can see the following .
1) A class subclasses a single parent. 2) A class subclasses a single parent and adds attributes 3) A class subclasses multiple parents 4) A class subclasses multiple parents with extra attributes 5) A class adds attributes at runtime 6) A class adds parents at runtime
I'm not too worried about adding interfaces at runtime, as that doesn't do anything more, really, than adding methods at runtime. Either way's fine, it's just a bit of extra provided metadata that's only there when you query it.
We're going to need to be able to do all these at runtime as well as load time, the question is how.
It's possible to just go ahead and do it *all* at runtime, and have no compile time component at all--just a series of "newclass, addparent, addattribute" ops, assuming those are the op names we go with. Classes just get created at code initialization time or something.
It's also possible that, except for case #1, all these things can only be done at compile time. (Which rules out 5 and 6) Classes are declared exclusively with some sort of bytecode metadata and to instantiate a new class you need a chunk of bytecode around. It's possible that at least some of this is only doable with metadata in bytecode, but the bytecode metadata segments can be easily created on the fly.
Case #1 will definitely want to be doable with a single op, at runtime. It's a reasonably common operation, as these things go, as folks make anonymous child classes for single objects. I know there are good reasons to be able to do that both from a user program standpoint as well as for internal reasons. (Mainly to allow per-object method overriding without having to go through too many hoops)
Part of me wants to go all-metadata for cases 2, 3, and 4, since I'm wary of the issues of doing what should be an atomic action in multiple ops. There's a loss of atomicity at the program level there, and if the classes override some of the actions (if we even allow that--does anyone allow overloading the subclassing operation?) it could get messy.
#5 really has to be metadata based, as it'll be expensive as it is. Refiguring the attribute array is a constant-time operation, more or less, so doing it 6 times to add in 6 attributes seems... suboptimal. If we don't do it with metadata we'll need ops that allow adding in multiple elements in one go.
#6, well... I'm not sure we should even allow #6, at least as part of the base parrot object system, but since we're going to do it anyway, we might as well do it right. The big issue with #6 being the same as #5--potentially needing to add in multiple attributes. That argues for a metadata approach, though alterations using metadata are dodgy.
Anyone got any feelings or opinions on this, besides "Why yes, I want an object system"? :) Class-based info I may be missing would also be welcome.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
