Dan Sugalski wrote:
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

Why not just have 1, 2 and 3 be degenerate cases 4?


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.

Would "adparent" replacate the metadata of the parent into the metadata of the child or will we need to walk the inheritence tree to get the
metadata about inherited attributes?



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.

Another possibility is to have an "addslots N" op to pre-extend the class and only dynamically extend if necessary.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]



Reply via email to