ziggy@hx.lcs.mit.edu (Michael R. Blair) (03/22/91)
I am trying to implement delegation atop CLOS using the meta-object protocol. Has anyone else attempted this with any degree of success? I am slowly becoming convinced that the meta-object protocol provides enough handles into the CLOS system to allow variations on the CLASS/INSTANCE view of OOPS, but that there may be too few handles to implementing DELEGATION-based OOPS. I can, of course, rationalize why CLOS might be class/instance biased but I am disappointed that the meta-object protocol doesn't seem to be headed toward loosening this bias. Of course, I am a meta-object neophyte so don't assume that I really know what I'm talking about... I am suffering more from an emotional response than from a technical dilemma: the pieces lay clearly before me and yet I do not see how to assemble them to do my biding. Anyone care to slap me awake by saying ``Obviosly, what you should do is <fill in the blank>''. I have a few half-baked approaches I have considered but they seem to lead to dead-ends. Here is my current thinking: [0] If I could allocate only direct slots in an instance along with a DELEGATE(S) slot to point to other objects to delegate through, then I could use slot-missing as a handle for delegating to find the remaining effective-slots. This lets me declare superclasses as usual to get all the lovely method inheritance for free. ---BUG: I see no elegant way to intercept the allocation to allocate space for only the direct slots. This also gives me no nice way to resolve one-name-several-slots problems (slot shadowing) while allowing access to all slots of a given name. [1] Failing that, I could intercept DEFCLASS on instances of the DELEGATES meta-class to make the slot definitions actually turn into just reader and writer methods closed over a shared local variable. Something vaguely like: ;;; defines a ``slot'' within the instance me (LET ((storage-cell '<we-dont-need-no-stinking-slots>)) (defmethod reader ((object (eql me))...args...) storage-cell) (defmethod writer ((object (eql me))...args...) (setq storage-cell ...))) Presumably some wild contortions on COMPUTE-APPLICABLE-METHODS and COMPUTE-DISCRIMINATING-FUNCTION could allow the use of CALL-NEXT-METHOD to search through all slots of the same name until the desired one is located... maybe hashing on the delegate instance to find the appropriate reader/writer. ---BUG: This looks unduly complicated... loads of meta-object surgery to by-pass the class/instance bias of CLOS would be needed, which I am not sure is logically necessary. [2] Give up and define a DELEGATE meta-class whose instances always have superclasses null. Do all the inheritance explicitly through the DELEGATES slot. ---BUG: How then could method inheritance be done? Looks like a total loss. Anyone have any more elegant approaches? ziggy@lcs.mit.edu (Michael R. Blair)