This will have to be quick, but... Objects, and Classes, and MetaClasses, oh my!
In the beginning, there is MMD. Ideally as a lexically and dynamically scoped first-class variable. Dispatching on argument types, value predicates, call site, current continuation, and all sorts of other useful things. The usual boring thing to do then is implicitly or explicitly call a dispatch function attached to the left-most participant. In an aggressive prototype-based system, you're done. The object has defined it's own dispatcher, or got one from a parent, perhaps the root object. In aristocratic systems, often an implicit dispatcher hands off the request to a please-dispatch-for-peon dispatcher in an associated classy noble. In systems where classy nobles are objects too, and thus have their own dispatcher, their dispatcher may be the same as please-dispatch-for-peon, or be completely different, or overlap. The classy object may feel the need to pass some combination of dispatcher and please-dispatch-for-peon requests up to a noble of its own. This hierarchy may be defined to taper off, or may appear infinite. The relationship of peons and nobles, and their capabilities, varies. Nobles can create new peons. Peons may or may not be able to create other peons. Nobles may or may not be able to create other nobles of similar stature -- they may have to appeal to a more noble noble to do it. It may or may not be possible to grant or take away nobility. (ObjectFactory-ness). Nobles may or may not be able to change. Either in fields, or methods, or both. If they can, this may or may not affect already created peons. Parts of their identity (name, pointer, uid, etc) may or may not change too. A peon may or may not be able to change without affecting it's noble. Same for a noble. And things can get... odd. For example, an object may accept requests to add a field, but then have this result in creating an new singleton class which inherits from the objects current parent, and then in visibly reparenting the object... or if the parent is already a singleton, in the singleton's silent mutation. And sometimes "singleton" classes can be asked to create additional objects. Weeee. The existing ops provide a vocabulary for describing solutions in this space. They may even be complete. So the question is how to clump and C-code them for convenient implementation of the languages we care most about. I've got to go. A table of design-question vs P5/P6/Py/Rb might help. Two often useful concepts I don't recall noticing in the discussion are that of Root objects distinct from Object and Class, and of mixins. Cheers, Mitchell
