"Richard O'Keefe" <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> 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.
