On Tue, Dec 8, 2020 at 8:02 PM Pascal Costanza <p...@p-cos.net> wrote:
> > 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 > https://github.com/pcostanza/contextl > > 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. > > ContextL has been used in production, so should count as relevant. > 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. > 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. > > 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. > 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). > > I think CLOS could be even more flexible, without loss of efficiency, but > that’s a different discussion. > > How about as flexible with improved efficiency for marginal inconvenience?
