I am interested to hear arguments in both directions. But you haven’t outlined the alternative, other than to state that they exist. What are these alternatives?
I use these MOP functions indirectly whenever I perform a CHANGE-CLASS on objects, mimicking something akin to Smalltalk BECOME. And yes, many (most?) of my apps are mutlithreaded. - DM > On Dec 6, 2020, at 9:52 PM, Jean-Claude Beaudoin > <jean.claude.beaud...@gmail.com> wrote: > > > Hello Pros of Common Lisp, > > Here is my attempt at starting a significant (and hopefully useful) debate on > a subject squarely about Common Lisp and its internals. > > My main stance here is to state that I have yet to see, in a significant > application, any use of functions #'cl:make-instance-obsolete and > #'cl:update-instance-for-redefined-class and of the underlying machinery that > support the remorphing of instances following a class redefinition (through a > subsequent cl:defclass most likely). I can state the same thing about > #'cl:update-instance-for-different-class and #'cl:change-class. > > The machinery required of any CL implementation to properly support those > functions (mentioned here above) is quite significant in its complexity and > usually imposes a sizeable performance penalty on the speed of any instance > slot access. > > A different choice of class redefinition semantics can lead to an > implementation of CLOS with much reduced instance slot access overhead. > > The necessity of supporting instance remorphing should therefore be well > motivated by very significant gains in application code performance (in speed > and/or size and/or expressiveness power). > > Can anyone of you point me to some evidence of such application level > usefulness? > Is there any notorious usecase of this (instance remorphing) since its > inclusion into ANSI CL? > > > By the way, at the bottom of the entry about #'cl:change-class in the text of > the CL standard, one can find a "Notes:" section that starts with this > sentence: "The generic function change-class has several semantic > difficulties." And this was written in the context of a single-threaded > implementation, as ANSI-CL limited itself. I bet that almost all currently > significant CL implementations are now multi-threaded, therefore the "several > semantic difficulties" are greatly and gravely compounded. In my opinion, > this makes proper motivation of usefulness all the more imperious. What do > you think? > >
