On Wed, Dec 9, 2020 at 3:59 AM Alessio Stalla <alessiosta...@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. >