<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 8, 2020 at 8:02 PM Pascal Costanza <<a href="mailto:pc@p-cos.net">pc@p-cos.net</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 style="overflow-wrap: break-word;"><br><div>The implementation of ContextL relies heavily on the CLOS MOP, and among other things on runtime class redefinition and corresponding updates of class instances. You can find the details how the class redefinition machinery is used in cx-partial-class.lisp at <a href="https://github.com/pcostanza/contextl" target="_blank">https://github.com/pcostanza/contextl</a></div><div><br></div><div>To the best of my knowledge, ContextL is one of the most efficient implementations of context-oriented programming (as compared to other implementations of COP for Java, Smalltalk, and a few other languages). This is because there is enough machinery in the CLOS MOP that provides the necessary dynamism and efficiency at the same time.</div><div><br></div><div>ContextL has been used in production, so should count as relevant.</div></div></blockquote><div><br></div><div>Thank you for the pointer to ContextL. I just cloned the repo and I'll browse the code to see if I can get properly educated thusly.</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 style="overflow-wrap: break-word;"><div><br></div><div>Removal of features can lead to more efficient implementation strategies, but also leads to less expressivity. It’s always difficult to draw a good line between what is good for most cases, and what is necessary for some. I, for one, am happy that CLOS MOP provides this amount of flexibility. There are enough OOP systems / languages with reduced expressivity (including ISLISP, Dylan, and some Scheme implementations) that we don’t necessarily need another one.</div><div><br></div><div>It has already been pointed out in this thread that you can always revert to the much more restricted defstruct. Maybe that one is too restrictive for your taste, but again, it is difficult to draw a good line between restrictive and expressive, and no compromise will make everybody happy.</div></div></blockquote><div><br></div><div>I am indeed of the opinion that the "line" has been drawn at the wrong level/place. That this choice has brought no real gain of expressiveness over what could have been provided in, say, a library. And that this choice has also brought very real overhead and "semantic difficulties" (as alluded in the ANSI-CL entry on #'CL:CHANGE-CLASS).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><br></div><div>I think CLOS could be even more flexible, without loss of efficiency, but that’s a different discussion.</div><div><br></div></div></blockquote><div><br></div><div>How about as flexible with improved efficiency for marginal inconvenience?</div><div> <br></div></div></div>