Saturday, March 25, 2006

Unfinished thoughts on object systems

Prototype-based object systems, plus aspect-oriented programming, plus multiple dispatch generic functions... hmm... The naive way to implement method dispatch and slot access in prototype-based object systems is to chain-up to the original object when a clone doesn't understand a message. This means potentially several indirections if the clone-chain is deep. Some language I saw recently claimed to be able to do single-dispatch method invocations using a maximum of three indirections. Hygenic mix-ins require lexical closures. If you have a mix-in that modifies the behaviour of an object and requires keeping additional state, you need to be positive that your state-keeping slot doesn't clash with an existing slot. It seems like method invocation could be called "resume environment", where the object represents an environment, that is, a set of bindings. In the multiple-dispatch generic function case, method specializers are real, actual objects, specifying a node in the clone tree. All the progeny (objects created by cloning) of the specializer object are considered subclasses of the progeny. Some support should be built programmatically for moving methods and slots around in the tree. This implies that methods are first-class objects. This is also necessary because adding advice to a function requires having access to the function object. This implies that behaviour is somehow external to objects, which seems to contradict the prototype-based system; unless some provision for "cloning" methods exists, and this sounds a lot like aspect-orientation: orthogonal extensions to behavior. What if they're not orthogonal, but more like behavioral mixins? You'd like to be able to replace, not just augment behavior. It would be really nice to do this in scheme in 10 lines using closures. What does a MOP look like for prototype-based object system? Unfinishedness...


Post a Comment

<< Home