In CLOS, instance remorphing considered useless in practice?

[Jean-Claude Beaudoin]

On Tue, Dec 8, 2020 at 3:21 PM dbm at refined-audiometrics.com <
dbm at refined-audiometrics.com> wrote:

> I am interested to hear arguments in both directions. But you haven’t
> outlined the alternative, other than to state that they exist. What are
> these alternatives?
>

 The main purpose of my original post was to solicit more information from
knowledgeable parties in order to do some kind of a survey of the situation
on the subject.  The subject of alternative semantics of class redefinition
is a very closely related subject of the original topic so I dropped a hint
of it in there as a teaser for a possible follow-up.

Let me elaborate a bit on what I meant.  One possible behavior of
CL:DEFCLASS could be to simply create a new class instance each time it is
invoked, no matter what happened before, and then install this brand new
class on the symbol that denotes it as the sole thus "properly named" class
from that point on. What would be wrong with that? The class that was the
previous "properly named" class would not be so "properly" anymore and
could merily go on to live its natural life on its own. Methods would have
to be re-loaded since all the previous signatures would still reference the
previous class. Is this re-loading not already happening to a large extent
since the said class has now seen its internal structure altered?



> I use these MOP functions indirectly whenever I perform a CHANGE-CLASS on
> objects, mimicking something akin to Smalltalk BECOME. And yes, many
> (most?) of my apps are mutlithreaded.
>
>
Can I ask why you invoke #'CL:CHANGE-CLASS on an object instead of simply
creating a new instance of the second class with adequate initialization?

My Smalltalk days are too far gone (20y ago) to remember what BECOME really
did, sorry.

Now, about the multi-threaded question, please imagine the following
situation. One good morning, two (or more) background threads happen to be
executing their business at the same priority level, each in their own
private dynamic environment, probably sleeping on some IO most of the
time.  And then, the master of the REPL decides to redefine a class that
has an instance that is part of each of the said thread dynamic
environments or that can be easily reached from them.  It then so happens
that the said
threads wake up and access that instance each at "almost the same time" and
for the first time since the class redefinition. In that situation, what
happens?  Do we simply duck, pray and hope for the best?  Or do we have
some way to ensure the proper order of the world? Currently, all I see for
the latter option are very heavy handed solutions like locks on every slot
access, or global locks that destroy the purpose of threads.  Am I simply
wrong on this or what?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20201209/7db0a6bb/attachment.html>