<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 9, 2020 at 3:59 AM Alessio Stalla <<a href="mailto:alessiostalla@gmail.com">alessiostalla@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>About multithreading, <b>all </b>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.</div></div></blockquote><div><br></div><div>Isn't "inline/not-inline" doing just what is needed in that area?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Still, we consider function redefinition a key feature of Common Lisp. So, redefinition of classes is in accordance with the spirit of the language.</div></div></blockquote><div><br></div><div>Redefinition of function is not "in situ". Why should redefinition of classes have to be so? I am not advocating against class redefinition!<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.<br></div></div>
</blockquote></div></div>