Hi Richard Indeed you are correct. We should continue to use and specialize postCopy. deepCopy and its friends such as veryDeepInnerInner …. do not smell good. Ideally I would like to remove all deepCopy and have a deepCopier that has a clear protocol and ask the objects. So may be at the end we will rewrite deepCopy but with tests and a clear semantics.
S/ > On 2 Jan 2021, at 02:32, Richard O'Keefe <rao...@gmail.com> wrote: > > Well, when you talk about "THE copying machinery" you have to be a bit more > specific. There is no such thing as #deepCopy or #shallowCopy in the ANSI > Smalltalk standard. Many Smalltalks have > Object>>copy > ^self shallowCopy postCopy > and encourage you to override #postCopy. > But nothing stops you doing > MyClass > methods for: 'copying' > copy > ^self > deepcopy > ^self > postCopy > ^self > shallowCopy > ^self > You will note that in Pharo, AtomicCollection, Behavior, Boolean, > Character, Float, SmallFloat64, Form, ColorForm, Morph, Paragraph, > Point, SmallInteger, String, UndefinedObject, and perhaps others > override #deepCopy. Also, Boolean, Character, Float, SmallFloat64, > SmallInteger, Symbol, UndefinedObject, and perhaps others > override #shallowCopy. > > So it *is* possible to have singletons in Smalltalk. > Classes can be copied in Pharo because someone thought it > would be a good idea. > > On to the next point. > 'I have an object whose internal state is updated > by incoming messages. I need to take immutable snapshots of that > object's state at some points. And that I do by sending "deepCopy" > and then "beRecursivelyReadOnlyObject".' > > You do not know which objects will be copied by #deepCopy and > which won't, or if you do, you cannot be sure that that will not > change in a future release, or indeed if you load a package. > You do not know whether some of these objects will break if made > read-only. > > #deepCopy is *serious* "Hic sunt dracones" territory. > It's marked on the Hunt-Lenox Globe, just beside the > Vesuvian introitus ad infernum. > > Seriously, the OOP way to do this is > MyClass>>immutableSnapshot > "Answer an immutable copy of myself." > ... > and then whatever it takes to make precisely that happen. > > > On Fri, 1 Jan 2021 at 23:35, Konrad Hinsen <konrad.hin...@fastmail.net > <mailto:konrad.hin...@fastmail.net>> wrote: > "Richard O'Keefe" <rao...@gmail.com <mailto:rao...@gmail.com>> writes: > > > #deepCopy is one of those things that is best avoided, > > because it violates the key principle of OOP that an > > In the abstract, I agree. In practice, I don't see what else I could do > for my use case. I have an object whose internal state is updated > by incoming messages. I need to take immutable snapshots of that > object's state at some points. And that I do by sending "deepCopy" > and then "beRecursivelyReadOnlyObject". > > Benoit St-Jean via Pharo-users <pharo-users@lists.pharo.org > <mailto:pharo-users@lists.pharo.org>> writes: > > > It never occurred to me that it would ever be the case! > > I've always thought classes were singleton and that SomeClass copy would > > always return the sole instance of that class! > > Me too. But after taking a closer look at how copy and deepCopy work, it > seems that maintaining singletons under copy operations is impossible. > There is no way to tell the copying machinery to return the original > object instead of making a new one. Unlike e.g. Python, where this is > possible and even quite common. > > Konrad.
