About multithreading, *all *kinds of redefinition have an impact. If I redefine a widely-used, low-level function, with hundreds of call sites – will each thread immediately call the new one without the bug, or will some still call the old one? Again, imposing a proper order would require protecting each function call with a lock, which is even worse for performance than protecting each slot access. Still, we consider function redefinition a key feature of Common Lisp. So, redefinition of classes is in accordance with the spirit of the language. Anecdotally, implementations that don't allow to redefine what Common Lisp doesn't mandate (e.g., in ABCL you cannot really redefine packages), in certain situations are painful to use, as they force you to delete & recreate everything, possibly even quitting Lisp and restarting.
On Wed, 9 Dec 2020 at 09:19, Nick Levine <n...@nicklevine.org> 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? > > Because you’d have to go find all the pointers to the old instance. Maybe > you don’t want to do that. Or maybe you don’t care, but that’s ok because > what CLOS gives you is possibilities. > > Class redefinition is cheap, in the sense that until you touch each > instance (i.e. passing it to a method) no work is done on it. I suspect — > but can’t remember the details — that cl:change-class recalculated slots on > the spot. > > - nick >
