On 9 Dec 2020, at 07:42, Jean-Claude Beaudoin <jean.claude.beaudoin@gmail.com> wrote:

On Tue, Dec 8, 2020 at 3:21 PM dbm@refined-audiometrics.com <dbm@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?