> On 9 Dec 2020, at 07:42, Jean-Claude Beaudoin > <jean.claude.beaud...@gmail.com> wrote: > > > > On Tue, Dec 8, 2020 at 3:21 PM d...@refined-audiometrics.com > <mailto:d...@refined-audiometrics.com> <d...@refined-audiometrics.com > <mailto:d...@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?
There is nothing wrong with that. In fact, you can already do that, thanks to (self find-class). > > 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? Praying and hoping is indeed not a good option. I’d rather double-check what the CL implementation of choice says what the semantics are. For example: http://www.lispworks.com/documentation/lw71/LW/html/lw-142.htm <http://www.lispworks.com/documentation/lw71/LW/html/lw-142.htm> Pascal -- Pascal Costanza
