Generic Delegation?

Here’s an issue that came up yesterday while trying to design a better READ-SEQUENCE for existing STREAM instances.

In Lispworks we have STREAM:STREAM-READ-SEQUENCE as a generic function against various classes of STREAMs.

I could construct an AUGMENTED-STREAM Class that encapsulates an open STREAM instance, and add a specialized method to STREAM:STREAM-READ-SEQUENCE. That works great. But now I also have to handle all the other generic functions that the enclosed STREAM object would have handled. And I don’t know the universe of generic functions to which the encapsulated stream should respond.

I don’t know of a fallback scheme in CLOS, akin to Smalltalk OBJECT’s DOES-NOT-UNDERSTAND message handler. Maybe there is one? If so, then this fallback could turn around in this AUGMENTED-STREAM case to delegate the message to the encapsulated STREAM. But CLOS isn’t really a message passing system.

One idea around this is to construct a mixin class such that any stream that has this mixin as a precedent prefix on its parent classes will perform a tailored method for READ-SEQUENCE. This allows the STREAM to handle all the other generic functions for itself.

But the AUGMENTED-STREAM must be created in situations where you already have an instance of some STREAM and you want to augment its behavior. You need to CHANGE-CLASS on the instance to a new class that pushes AUGMENTED-STREAM to the fore of the parent class list. This might be feasible, but probably involves some MetaObject protocol.

(What I actually did yesterday is, I said all of these efforts are trying to flip a light switch from afar using a long pole. Why not just call a specialized function directly? And so I have READ-RAW-VECTOR in place of READ-STREAM. But the above questions still remain.)

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html