On Wed, Dec 9, 2020 at 3:59 AM Alessio Stalla alessiostalla@gmail.com wrote:
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.
Isn't "inline/not-inline" doing just what is needed in that area?
Still, we consider function redefinition a key feature of Common Lisp. So,
redefinition of classes is in accordance with the spirit of the language.
Redefinition of function is not "in situ". Why should redefinition of classes have to be so? I am not advocating against class redefinition!
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.