In CLOS, instance remorphing considered useless in practice?

[Jean-Claude Beaudoin]

On Tue, Dec 8, 2020 at 8:02 PM Pascal Costanza <pc at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201209/8fe704ce/attachment.html>