Re: Generic Delegation?

It appears that the only way, in CLOS, to have Blind Delegation†, is to wrap an instance with a mixin class. In that way, any methods that you don’t override on the mixin will become automatically dispatched on the original instance class. And the instance retains its abilities for other functions.

†Blind-Delegation: Delegating behaviors to an object without knowing in advance what may be asked of it.



(defun wrap-instance-with-mixin (obj &key mixin-class class-name)
  (let* ((mixin-class  (if (symbolp mixin-class)
                           (find-class mixin-class)
                         mixin-class))
         (obj-class    (class-of obj))
         (class-name   (cond ((null class-name)
                              (intern (concatenate 'string
                                                   (string (class-name mixin-class))
                                                   #\-
                                                   (string (class-name obj-class)))
                                      (find-package :com.ral.useful-macros)))
                             
                             ((symbolp class-name)
                              class-name)

                             (t
                              (intern (string class-name)
                                      (find-package :com.ral.useful-macros)))
                             ))
         (bridge-class  (#+:LISPWORKS clos:ensure-class
                         #+:SBCL      sb-mop:ensure-class
                                      class-name
                                      :direct-superclasses (list mixin-class obj-class)
                                      :metaclass           (class-of obj-class))))
    (change-class obj bridge-class)))



> On Nov 9, 2025, at 09:04, David McClain <[email protected]> wrote:
> 
> I just found this reference which addresses some of the issues I’m asking about...
> 
> https://www.dreamsongs.com/Files/clos-book.pdf
> 
>> On Nov 9, 2025, at 08:31, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>> 
>> 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
>