Just as an aside… that DSP prototyping environment still runs today as well as it did back in 2008 (perhaps a bit faster on todays CPUs). That is one thing about Common Lisp that I value highly. I have code that I wrote almost 30 years ago and have never needed to change, while it is still very much in use today.
I contrast that experience with programming in Rust just a year ago, while the entire language was changing beneath me almost monthly. - DM > On Dec 9, 2020, at 7:55 AM, d...@refined-audiometrics.com wrote: > >> Can I ask why you invoke #'CL:CHANGE-CLASS on an object instead of simply >> creating a new instance of the second class with adequate initialization? >> > > I have used CHANGE-CLASS sparingly over the years. My first use was in a > graphical DSP algorithm prototyping environment, and I believe it was related > to graphical display objects. Almost a decade ago, so my memory is rusty. > > But most recently I have a class hierarchy of objects, where some more > refined subclass instances can act one way through an initial mixin class on > their first execution of a principal method, and then revert back to other > superclass behavior thereafter. > > On CHANGE-CLASS, there is elision of slots in dropping back the the principal > superclass structure. But every other slot remains intact. > > I cannot simply re-MAKE-INSTANCE on these objects as their identity is > referenced in many places elsewhere. And what I need is a change in behavior, > not identity. The only way to accomplish this change along the lines of > re-making them, would require yet another layer of indirection. That might be > interesting to contemplate. > > - DM > >
