Well, we can make objects and we can call methods on objects (at
least the interface is specified, if not actually implemented) but
actually building classes to make objects out of is still
unspecified. So, time to remedy that, after which I hope we can build
at least a simple "ParrotObject" class.

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
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk