What I said just now is true, but it doesn't tell the whole story. It turns out that Squeak, VisualWorks, GNU Smalltalk, and Pharo *deliberately* make aClass copy return a new class with the same superclass and methods (but no subclasses). Dolphin and VisualAge do not. So if you don't want to make copies of classes, you must avoid ALL of #deepCopy, #shallowCopy, AND #copy.
On Fri, 1 Jan 2021 at 13:59, Richard O'Keefe <rao...@gmail.com> wrote: > #deepCopy is one of those things that is best avoided, > because it violates the key principle of OOP that an > object is in charge of its own data and behaviour. > It can not so much break invariants as crush them and > bury them in an unmarked grave, just like #shallowCopy. > > > > On Fri, 1 Jan 2021 at 03:25, Konrad Hinsen <konrad.hin...@fastmail.net> > wrote: > >> On 31/12/2020 12:19, Konrad Hinsen wrote: >> >> > It's been a while since I have encountered mysterious behavior in >> > Pharo, but today it happened. I set up a dictionary with classes as >> > keys, and got "Key not found" errors for keys that were definitely in >> > my dictionary. A quick debugging session showed the underlying issue: >> > I had two references to a class which look the same when inspected, >> > but turn out to be not identical (==) and thus not equal (=). How can >> > this happen? >> >> >> Update, after a few more debugging sessions: my dictionary is the result >> of a deepCopy operation, meaning the class has been copied. And the copy >> of a class is indeed a distinct but otherwise indistinguishable class. >> 'Object copy = Object' is 'false'. >> >> >> Konrad. >> >
