Re: Generic Delegation?

I think the idea of using mixin classes is more general that inventing new subclasses. 

I can define a mixin class and add methods specialized to just it. Then later I can combine the mixin class with arbitrary other classes to produce subclasses, either statically in the source code, or dynamically on the fly, without ever needing to know the class details of those other classes.

> On Nov 10, 2025, at 02:20, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
> 
> I have an instance of a Socket Stream handed to me. It came from somewhere else. So it already exists, and it is too late to make a subclass instance. The instance already exists.
> 
> But I want this particular instance to be able to READ-SEQUENCE into raw vectors of single-precision floating point values coming at me from a remote telemetry source. The remote source was written in C and simply pushes a type-case array of floats out the Socket port as thought it were an array of unsigned bytes.
> 
> Now I already solved this problem by inventing a READ-RAW-VECTOR function. That is one approach.
> 
> Another approach is to forcibly wrap the Socket Stream instance with a mixin class, and have special overrides on READ-SEQUENCE programmed for the mixin class.
> 
> There are two ways to wrap an instance with a mixin class. 
> 
> One way is to construct an envelope instance that contains the original Socket Stream as an element in a slot. But then you have to repeat all the methods that the Socket Stream is supposed to respond to by forwarding the method calls to the contained Socket Stream, for those methods that you don’t want to override. And in order to do that, you have to know what minimum functionality the Socket Stream is expected to provide.
> 
> I think this is the method conventionally referred to as Delegation in CLOS.
> 
> The other way to wrap the instance in the way I just showed - invent (ensure) a hybrid class with a mixin prefixed to the parent class list of the instance class, and then CHANGE-CLASS the instance to that new hybrid class. The does the same thing as your subclassing, but happens after the instance has already been constructed. Now we don’t need to know or care what other behaviors the instance has. We can simply override the methods that we need to override.
> 
> This is the CLOS equivalent of Smalltalk's DONT-UNDERSTAND protocol.
> 
> 
> 
>> On Nov 10, 2025, at 01:34, Yuri Davidovsky (as work at disclosure dot ie) <[email protected]> wrote:
>> 
>> 
>>> On 9 Nov 2025, at 16:32, David McClain (as dbm at refined-audiometrics dot com) <[email protected]> wrote:
>>> 
>>> 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.
>> 
>> I may be misunderstanding what you are trying to do, judging by the complexity of your solution, but to me it seems that you want to simply subclass the stream class whose functionality you want to modify. Then you can override the specific behaviour that you need, while the rest of the functionality you do not care about will be handled by the parent class methods.
>> 
>> Or are you trying to do something else that I did not understand correctly?
>> 
>> _______________________________________________
>> Lisp Hug - the mailing list for LispWorks users
>> [email protected]
>> http://www.lispworks.com/support/lisp-hug.html
> 
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html


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