Can a class be not equal to itself?
Hi everyone,
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?
Konrad.
Hi Konrad,
Could it be that you have overridden = on the class side of your class?
Otherwise, I do not see how this can happen.
Cheers,
Tudor
On Dec 31, 2020, at 12:19 PM, Konrad Hinsen konrad.hinsen@fastmail.net wrote:
Hi everyone,
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?
Konrad.
--
feenk.com
"It's not how it is, it is how we see it."
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.
#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.hinsen@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.
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 raoknz@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.hinsen@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.
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!
I wonder what are the implications of returning a copy, say, when you
add an instVar to the "original" class ? What happens to the reshaping
of the instances created by the copy?
On 2020-12-31 20:25, Richard O'Keefe wrote:
Squeak, VisualWorks,
GNU Smalltalk, and Pharo deliberately make
aClass copy
--
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
GitHub: bstjean
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)
"Richard O'Keefe" raoknz@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.
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.hinsen@fastmail.net
wrote:
"Richard O'Keefe" raoknz@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.
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 raoknz@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.hinsen@fastmail.net mailto:konrad.hinsen@fastmail.net> wrote:
"Richard O'Keefe" <raoknz@gmail.com mailto:raoknz@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.
"Richard O'Keefe" raoknz@gmail.com writes:
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
I am referring only to Pharo, which is the only Smalltalk I have ever
used.
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.
Interesting. I didn't even consider this possibility because the comment
in Object>>#deepCopy says "should never be overridden".
#deepCopy is serious "Hic sunt dracones" territory.
It's marked on the Hunt-Lenox Globe, just beside the
Vesuvian introitus ad infernum.
:-) That's more or less what I discovered in my recent debugging
experiment.
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.
In other words, implement my own variant of deepCopy. That's probably
the safest way to go, but it also means there is no extensible
copying infrastructure that everybody can build on.
Konrad.