Smalltalk › Cincom › VisualWorks

identityHash and become: question

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

15 messages Options

Roel Wuyts

identityHash and become: question

Hello,

I have a question regarding identityHash and become. Consider the
following piece of code:

| assoc1 assoc2 assoc1Hash assoc2Hash |
assoc1 := Core.Association key: 1 value: 3.
assoc1Hash := assoc1 identityHash.
assoc2 := Core.Association key: 4 value: 7.
assoc2Hash := assoc2 identityHash.
assoc2 become: assoc1.
assoc2 identityHash = assoc2Hash

Is it guaranteed that the last line always is true ?

This strikes me as bizarre. but in the comment of identityHash both
could be possible. On the one hand it says that "for objects that are
not == the hash values might or might not be the same" (which sounds
reasonable to me). On the other hand, it says "The identityHash value
does not change across the life of the object". I'm lost at what
happens in the end. Any suggestions ?

--
Roel

Reinout Heeck-2

Re: identityHash and become: question

Roel Wuyts wrote:

> Hello,
>
> I have a question regarding identityHash and become. Consider the
> following piece of code:
>
> | assoc1 assoc2 assoc1Hash assoc2Hash |
> assoc1 := Core.Association key: 1 value: 3.
> assoc1Hash := assoc1 identityHash.
> assoc2 := Core.Association key: 4 value: 7.
> assoc2Hash := assoc2 identityHash.
> assoc2 become: assoc1.
> assoc2 identityHash = assoc2Hash
>
>
> Is it guaranteed that the last line always is true ?
>
> This strikes me as bizarre.

Me too, this seems like a bug to me.
Become is implemented by swapping the pointers to the object bodies in
the corresponding object table entries.

If identityHash is cached in the OT (I don't know if this is true) then
these hash entries should be swapped too IMO.

R
-

> but in the comment of identityHash both
> could be possible. On the one hand it says that "for objects that are
> not == the hash values might or might not be the same" (which sounds
> reasonable to me). On the other hand, it says "The identityHash value
> does not change across the life of the object". I'm lost at what happens
> in the end. Any suggestions ?
>
> --
> Roel
>
>

Terry Raymond

RE: identityHash and become: question

In reply to this post by Roel Wuyts

At first glance your thinking appears correct. However,
suppose you are using the identity hash as a uuid for
an object and you do a become. The uuid should now be
the same as the new object, not the old because you are
using the uuid as an integer reference. This is precisely
what your example code does.

Terry

===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Roel Wuyts [mailto:[hidden email]]
> Sent: Thursday, June 01, 2006 9:03 AM
> To: vw-nc
> Subject: identityHash and become: question
>
> Hello,
>
> I have a question regarding identityHash and become. Consider the
> following piece of code:
>
> | assoc1 assoc2 assoc1Hash assoc2Hash |
> assoc1 := Core.Association key: 1 value: 3.
> assoc1Hash := assoc1 identityHash.
> assoc2 := Core.Association key: 4 value: 7.
> assoc2Hash := assoc2 identityHash.
> assoc2 become: assoc1.
> assoc2 identityHash = assoc2Hash
>
>
> Is it guaranteed that the last line always is true ?
>
> This strikes me as bizarre. but in the comment of identityHash both
> could be possible. On the one hand it says that "for objects that are
> not == the hash values might or might not be the same" (which sounds
> reasonable to me). On the other hand, it says "The identityHash value
> does not change across the life of the object". I'm lost at what
> happens in the end. Any suggestions ?
>
> --
> Roel

Martin McClure

Re: identityHash and become: question

In reply to this post by Roel Wuyts

Roel Wuyts wrote:

I believe so.

>
> This strikes me as bizarre.

#become: *is* bizarre. It actually changes the identity of objects,
which is non-intuitive at best.

That said, I think this is the correct behavior. #identityHash should
depend on the object's identity, not its class or state. An object's
state can be changed by instance variable assignment, its class can be
changed by #adoptInstance:, but only #become: changes its identity.

Regards,

-Martin

Vassili Bykov

Re: identityHash and become: question

In reply to this post by Reinout Heeck-2

> If identityHash is cached in the OT (I don't know if this is true) then
> these hash entries should be swapped too IMO.

It is true, identityHash is a 14 bit value stored in the object header
(a more appropriate term than an object table entry). As Terry already
pointed out, the values should not be swapped, or at least this is not a
cut-and-dry proposition. Basically, it's a question of what object
identity really is. Is identity something inherent in the object, or is
it in the relationship between the rest of the world and this object?

Historically, Smalltalk "always" subscribed to the latter viewpoint.
#identityHash is a replacement of #asOop. asOop was a selector in ST-80
understood by any object and returning its index in the OT. (The inverse
operation was called #asObject, a method of integers). #asOop was used
as hash function by IdentitySet and IdentityDictionary. When object
table as an array of objects was eliminated and the concept of an oop as
a table index disappeared, #identityHash was introduced to keep identity
hashed collections working. Obviously, the behavior of #identityHash
with respect to #become: repeats the original behavior of #asOop--and
both imply that identity is in the references, not in the object.
Becomes swaps identities, not just switches references.

--
Vassili Bykov <[hidden email]>

[:s | s, s printString] value: '[s: | s, s printString] value: '

Reinout Heeck

Re: identityHash and become: question

Given the asOop history this all makes sense, however since we now
have a random number as the 'oop' the whole thing makes less sense.
Terry still uses the identityHash as an oop (eg in the
ProcessMonitor) but given that this oop is only 14 random bits there
is a lot of potential for clashes.

I wasn't introduced to Smalltalk during this asOop timeframe so as a
relative newbie seeing the selector name xxxHash I'd expect it to
behave along the lines of #hash, ie connected to the object, not to
the references.
Moreover I find the concept of 'swapping references' a very easy one
to reason about and as you observed the current identityHash behavior
runs counter to that way of reasoning.

I would have been helped a lot if the comment of identityHash
explained this history of using asOop as a reference rather than
seeing identityHash as an aspect of the object. (Or as Roel noted
the current comment is broken in the light op #become:)

Would changing it's behavior to the expected one (by Roel and me at
least ;-) break any code?
It would be one of those enhancements towards 'regularizing' the VW
base image and making it easier to grok for newcomers. IOW are there
still significant abuses of identityHash as an oop or would it 'just
work'? (Assuming #become: is never used on a Process the
ProcessMonitor wouldn't break ;-)

Can people here tell me the behavior of identityHash across becomes
in other dialects please, I'm curious now...

R
-

On Jun 1, 2006, at 7:05 PM, Vassili Bykov wrote:

>> If identityHash is cached in the OT (I don't know if this is true)
>> then these hash entries should be swapped too IMO.
>
> It is true, identityHash is a 14 bit value stored in the object
> header (a more appropriate term than an object table entry). As
> Terry already pointed out, the values should not be swapped, or at
> least this is not a cut-and-dry proposition. Basically, it's a
> question of what object identity really is. Is identity something
> inherent in the object, or is it in the relationship between the
> rest of the world and this object?
>
> Historically, Smalltalk "always" subscribed to the latter
> viewpoint. #identityHash is a replacement of #asOop. asOop was a
> selector in ST-80 understood by any object and returning its index
> in the OT. (The inverse operation was called #asObject, a method of
> integers). #asOop was used as hash function by IdentitySet and
> IdentityDictionary. When object table as an array of objects was
> eliminated and the concept of an oop as a table index disappeared,
> #identityHash was introduced to keep identity hashed collections
> working. Obviously, the behavior of #identityHash with respect to
> #become: repeats the original behavior of #asOop--and both imply
> that identity is in the references, not in the object. Becomes
> swaps identities, not just switches references.
>
> --
> Vassili Bykov <[hidden email]>
>
> [:s | s, s printString] value: '[s: | s, s printString] value: '
>
>

Terry Raymond

RE: identityHash and become: question

Reinout

If you consider that the identity hash is used as the
index into the IdentityDictionary it has to work as it
is currently implemented. Otherwise, if you become the key
then when you do the next lookup you will get the old
object instead of the swapped object.

Terry

===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Reinout Heeck [mailto:[hidden email]]
> Sent: Thursday, June 01, 2006 4:19 PM
> To: vw-nc
> Subject: Re: identityHash and become: question
>
> Given the asOop history this all makes sense, however since we now
> have a random number as the 'oop' the whole thing makes less sense.
> Terry still uses the identityHash as an oop (eg in the
> ProcessMonitor) but given that this oop is only 14 random bits there
> is a lot of potential for clashes.
>
> I wasn't introduced to Smalltalk during this asOop timeframe so as a
> relative newbie seeing the selector name xxxHash I'd expect it to
> behave along the lines of #hash, ie connected to the object, not to
> the references.
> Moreover I find the concept of 'swapping references' a very easy one
> to reason about and as you observed the current identityHash behavior
> runs counter to that way of reasoning.
>
> I would have been helped a lot if the comment of identityHash
> explained this history of using asOop as a reference rather than
> seeing identityHash as an aspect of the object. (Or as Roel noted
> the current comment is broken in the light op #become:)
>
> Would changing it's behavior to the expected one (by Roel and me at
> least ;-) break any code?
> It would be one of those enhancements towards 'regularizing' the VW
> base image and making it easier to grok for newcomers. IOW are there
> still significant abuses of identityHash as an oop or would it 'just
> work'? (Assuming #become: is never used on a Process the
> ProcessMonitor wouldn't break ;-)
>
>
> Can people here tell me the behavior of identityHash across becomes
> in other dialects please, I'm curious now...
>
>
> R
> -
>
>
> On Jun 1, 2006, at 7:05 PM, Vassili Bykov wrote:
>
> >> If identityHash is cached in the OT (I don't know if this is true)
> >> then these hash entries should be swapped too IMO.
> >
> > It is true, identityHash is a 14 bit value stored in the object
> > header (a more appropriate term than an object table entry). As
> > Terry already pointed out, the values should not be swapped, or at
> > least this is not a cut-and-dry proposition. Basically, it's a
> > question of what object identity really is. Is identity something
> > inherent in the object, or is it in the relationship between the
> > rest of the world and this object?
> >
> > Historically, Smalltalk "always" subscribed to the latter
> > viewpoint. #identityHash is a replacement of #asOop. asOop was a
> > selector in ST-80 understood by any object and returning its index
> > in the OT. (The inverse operation was called #asObject, a method of
> > integers). #asOop was used as hash function by IdentitySet and
> > IdentityDictionary. When object table as an array of objects was
> > eliminated and the concept of an oop as a table index disappeared,
> > #identityHash was introduced to keep identity hashed collections
> > working. Obviously, the behavior of #identityHash with respect to
> > #become: repeats the original behavior of #asOop--and both imply
> > that identity is in the references, not in the object. Becomes
> > swaps identities, not just switches references.
> >
> > --
> > Vassili Bykov <[hidden email]>
> >
> > [:s | s, s printString] value: '[s: | s, s printString] value: '
> >
> >

Michel Tilman

Re: identityHash and become: question

Now you can create identity sets with multiple equal (==) elements,
which is also weird:

| p1 p2 set |

p1 := 0@0.
p2 := 1@1.
set := IdentitySet new.
set add: p1; add: p2.
p2 oneWayBecome: p1.
set => IdentitySet (0@0 0@0) with two == elements

michel

On 01 Jun 2006, at 23:35, Terry Raymond wrote:

> Reinout
>
> If you consider that the identity hash is used as the
> index into the IdentityDictionary it has to work as it
> is currently implemented. Otherwise, if you become the key
> then when you do the next lookup you will get the old
> object instead of the swapped object.
>
> Terry
>
> ===========================================================
> Terry Raymond Smalltalk Professional Debug Package
> Crafted Smalltalk
> 80 Lazywood Ln.
> Tiverton, RI 02878
> (401) 624-4517 [hidden email]
> <http://www.craftedsmalltalk.com>
> ===========================================================
>
>> -----Original Message-----
>> From: Reinout Heeck [mailto:[hidden email]]
>> Sent: Thursday, June 01, 2006 4:19 PM
>> To: vw-nc
>> Subject: Re: identityHash and become: question
>>
>> Given the asOop history this all makes sense, however since we now
>> have a random number as the 'oop' the whole thing makes less sense.
>> Terry still uses the identityHash as an oop (eg in the
>> ProcessMonitor) but given that this oop is only 14 random bits there
>> is a lot of potential for clashes.
>>
>> I wasn't introduced to Smalltalk during this asOop timeframe so as a
>> relative newbie seeing the selector name xxxHash I'd expect it to
>> behave along the lines of #hash, ie connected to the object, not to
>> the references.
>> Moreover I find the concept of 'swapping references' a very easy one
>> to reason about and as you observed the current identityHash behavior
>> runs counter to that way of reasoning.
>>
>> I would have been helped a lot if the comment of identityHash
>> explained this history of using asOop as a reference rather than
>> seeing identityHash as an aspect of the object. (Or as Roel noted
>> the current comment is broken in the light op #become:)
>>
>> Would changing it's behavior to the expected one (by Roel and me at
>> least ;-) break any code?
>> It would be one of those enhancements towards 'regularizing' the VW
>> base image and making it easier to grok for newcomers. IOW are there
>> still significant abuses of identityHash as an oop or would it 'just
>> work'? (Assuming #become: is never used on a Process the
>> ProcessMonitor wouldn't break ;-)
>>
>>
>> Can people here tell me the behavior of identityHash across becomes
>> in other dialects please, I'm curious now...
>>
>>
>> R
>> -
>>
>>
>> On Jun 1, 2006, at 7:05 PM, Vassili Bykov wrote:
>>
>>>> If identityHash is cached in the OT (I don't know if this is true)
>>>> then these hash entries should be swapped too IMO.
>>>
>>> It is true, identityHash is a 14 bit value stored in the object
>>> header (a more appropriate term than an object table entry). As
>>> Terry already pointed out, the values should not be swapped, or at
>>> least this is not a cut-and-dry proposition. Basically, it's a
>>> question of what object identity really is. Is identity something
>>> inherent in the object, or is it in the relationship between the
>>> rest of the world and this object?
>>>
>>> Historically, Smalltalk "always" subscribed to the latter
>>> viewpoint. #identityHash is a replacement of #asOop. asOop was a
>>> selector in ST-80 understood by any object and returning its index
>>> in the OT. (The inverse operation was called #asObject, a method of
>>> integers). #asOop was used as hash function by IdentitySet and
>>> IdentityDictionary. When object table as an array of objects was
>>> eliminated and the concept of an oop as a table index disappeared,
>>> #identityHash was introduced to keep identity hashed collections
>>> working. Obviously, the behavior of #identityHash with respect to
>>> #become: repeats the original behavior of #asOop--and both imply
>>> that identity is in the references, not in the object. Becomes
>>> swaps identities, not just switches references.
>>>
>>> --
>>> Vassili Bykov <[hidden email]>
>>>
>>> [:s | s, s printString] value: '[s: | s, s printString] value: '
>>>
>>>
>
>

Vassili Bykov

Re: identityHash and become: question

In reply to this post by Reinout Heeck

Reinout Heeck wrote:
> Would changing it's behavior to the expected one (by Roel and me at
> least ;-) break any code?
>
> It would be one of those enhancements towards 'regularizing' the VW base
> image and making it easier to grok for newcomers. IOW are there still
> significant abuses of identityHash as an oop or would it 'just work'?

The problem here is not with abuses of #identityHash as #anOop, it's
with using it for the intended purpose. If #become: swaps identity
hashes, then after

anIdSet add: foo.
foo become: bar.

the following will be true as expected:

anIdSet anySatisfy: [:any | any == foo]

but this:

anIdSet includes: foo

will be false with probability very close to 1, unless #become: also
takes care to find each identity-hashed collection the receiver or the
argument are elements/keys of and rehash it.

The thing here is that current behavior of identityHash has deeper
justification than only compatibility with asOop. In Smalltalk, we
always work with objects through references and never directly, so
references really are pretty fundamental entities. "Basic" identity is
easier to define an artifact of references and not of objects. You are
free, of course, to give "inherent" identity to your own objects by
giving them some kind of a UID attribute.

> (Assuming #become: is never used on a Process the ProcessMonitor
> wouldn't break ;-)
>
>
> Can people here tell me the behavior of identityHash across becomes in
> other dialects please, I'm curious now...
>
>
> R
> -
>
>
> On Jun 1, 2006, at 7:05 PM, Vassili Bykov wrote:
>
>>> If identityHash is cached in the OT (I don't know if this is true)
>>> then these hash entries should be swapped too IMO.
>>
>> It is true, identityHash is a 14 bit value stored in the object header
>> (a more appropriate term than an object table entry). As Terry already
>> pointed out, the values should not be swapped, or at least this is not
>> a cut-and-dry proposition. Basically, it's a question of what object
>> identity really is. Is identity something inherent in the object, or
>> is it in the relationship between the rest of the world and this object?
>>
>> Historically, Smalltalk "always" subscribed to the latter viewpoint.
>> #identityHash is a replacement of #asOop. asOop was a selector in
>> ST-80 understood by any object and returning its index in the OT. (The
>> inverse operation was called #asObject, a method of integers). #asOop
>> was used as hash function by IdentitySet and IdentityDictionary. When
>> object table as an array of objects was eliminated and the concept of
>> an oop as a table index disappeared, #identityHash was introduced to
>> keep identity hashed collections working. Obviously, the behavior of
>> #identityHash with respect to #become: repeats the original behavior
>> of #asOop--and both imply that identity is in the references, not in
>> the object. Becomes swaps identities, not just switches references.
>>
>> --Vassili Bykov <[hidden email]>
>>
>> [:s | s, s printString] value: '[s: | s, s printString] value: '
>>
>>
>
>

--
Vassili Bykov <[hidden email]>

[:s | s, s printString] value: '[s: | s, s printString] value: '

Dennis smith-4

Re: identityHash and become: question

In reply to this post by Michel Tilman

But them become: is not something you should be using except in some
very specialized, low-level (low as in part of the base classes) situations.

Michel Tilman wrote:

> Now you can create identity sets with multiple equal (==) elements,
> which is also weird:
>
> | p1 p2 set |
>
> p1 := 0@0.
> p2 := 1@1.
> set := IdentitySet new.
> set add: p1; add: p2.
> p2 oneWayBecome: p1.
> set => IdentitySet (0@0 0@0) with two == elements
>
> michel
>
>
>
> On 01 Jun 2006, at 23:35, Terry Raymond wrote:
>
>> Reinout
>>
>> If you consider that the identity hash is used as the
>> index into the IdentityDictionary it has to work as it
>> is currently implemented. Otherwise, if you become the key
>> then when you do the next lookup you will get the old
>> object instead of the swapped object.
>>
>> Terry
>>
>> ===========================================================
>> Terry Raymond Smalltalk Professional Debug Package
>> Crafted Smalltalk
>> 80 Lazywood Ln.
>> Tiverton, RI 02878
>> (401) 624-4517 [hidden email]
>> <http://www.craftedsmalltalk.com>
>> ===========================================================
>>
>>> -----Original Message-----
>>> From: Reinout Heeck [mailto:[hidden email]]
>>> Sent: Thursday, June 01, 2006 4:19 PM
>>> To: vw-nc
>>> Subject: Re: identityHash and become: question
>>>
>>> Given the asOop history this all makes sense, however since we now
>>> have a random number as the 'oop' the whole thing makes less sense.
>>> Terry still uses the identityHash as an oop (eg in the
>>> ProcessMonitor) but given that this oop is only 14 random bits there
>>> is a lot of potential for clashes.
>>>
>>> I wasn't introduced to Smalltalk during this asOop timeframe so as a
>>> relative newbie seeing the selector name xxxHash I'd expect it to
>>> behave along the lines of #hash, ie connected to the object, not to
>>> the references.
>>> Moreover I find the concept of 'swapping references' a very easy one
>>> to reason about and as you observed the current identityHash behavior
>>> runs counter to that way of reasoning.
>>>
>>> I would have been helped a lot if the comment of identityHash
>>> explained this history of using asOop as a reference rather than
>>> seeing identityHash as an aspect of the object. (Or as Roel noted
>>> the current comment is broken in the light op #become:)
>>>
>>> Would changing it's behavior to the expected one (by Roel and me at
>>> least ;-) break any code?
>>> It would be one of those enhancements towards 'regularizing' the VW
>>> base image and making it easier to grok for newcomers. IOW are there
>>> still significant abuses of identityHash as an oop or would it 'just
>>> work'? (Assuming #become: is never used on a Process the
>>> ProcessMonitor wouldn't break ;-)
>>>
>>>
>>> Can people here tell me the behavior of identityHash across becomes
>>> in other dialects please, I'm curious now...
>>>
>>>
>>> R
>>> -
>>>
>>>
>>> On Jun 1, 2006, at 7:05 PM, Vassili Bykov wrote:
>>>
>>>>> If identityHash is cached in the OT (I don't know if this is true)
>>>>> then these hash entries should be swapped too IMO.
>>>>
>>>> It is true, identityHash is a 14 bit value stored in the object
>>>> header (a more appropriate term than an object table entry). As
>>>> Terry already pointed out, the values should not be swapped, or at
>>>> least this is not a cut-and-dry proposition. Basically, it's a
>>>> question of what object identity really is. Is identity something
>>>> inherent in the object, or is it in the relationship between the
>>>> rest of the world and this object?
>>>>
>>>> Historically, Smalltalk "always" subscribed to the latter
>>>> viewpoint. #identityHash is a replacement of #asOop. asOop was a
>>>> selector in ST-80 understood by any object and returning its index
>>>> in the OT. (The inverse operation was called #asObject, a method of
>>>> integers). #asOop was used as hash function by IdentitySet and
>>>> IdentityDictionary. When object table as an array of objects was
>>>> eliminated and the concept of an oop as a table index disappeared,
>>>> #identityHash was introduced to keep identity hashed collections
>>>> working. Obviously, the behavior of #identityHash with respect to
>>>> #become: repeats the original behavior of #asOop--and both imply
>>>> that identity is in the references, not in the object. Becomes
>>>> swaps identities, not just switches references.
>>>>
>>>> --
>>>> Vassili Bykov <[hidden email]>
>>>>
>>>> [:s | s, s printString] value: '[s: | s, s printString] value: '
>>>>
>>>>
>>
>>
>

--
Dennis Smith [hidden email]
Cherniak Software Development Corporation +1 905.771.7011
400-10 Commerce Valley Dr E Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7 http://www.CherniakSoftware.com

Michel Tilman

Re: identityHash and become: question

On 02 Jun 2006, at 00:32, Dennis Smith wrote:

> But them become: is not something you should be using except in some
> very specialized, low-level (low as in part of the base classes)
> situations.
>
> Michel Tilman wrote:
>> Now you can create identity sets with multiple equal (==)
>> elements, which is also weird:
>>
>> | p1 p2 set |
>>
>> p1 := 0@0.
>> p2 := 1@1.
>> set := IdentitySet new.
>> set add: p1; add: p2.
>> p2 oneWayBecome: p1.
>> set => IdentitySet (0@0 0@0) with two == elements
>>
>> michel

I know, and this is a point I wanted to illustrate. Become: and
variants are currently only (reasonably) transparent at the state
level, not at the behavioral level (semantics of a class). Yet some
of the arguments I heard seem to illustrate that the current
situation works out in some behavioral cases, but this is not
consistent. Hence in the current state discussions should only
address the - what you call - low-level view.

In practice, the way to refer to an object is by means of variables.
We could say that a variable holds the object or that it refers to
the object. Now it seems we must say: a variable refers to a (largely
invisble) reference to the object. We can have a single object,
different references (at least with different id hashes) to the
object, and some variables holding on to the same reference to the
same object, and another group of variables containing another
reference to the same object. Hence the explicit concept of a
reference is there, but only vaguely. I a a bit uneasy with all this.

michel

Reinout Heeck-2

Re: identityHash and become: question

In reply to this post by Terry Raymond

Terry Raymond wrote:
> If you consider that the identity hash is used as the
> index into the IdentityDictionary it has to work as it
> is currently implemented. Otherwise, if you become the key
> then when you do the next lookup you will get the old
> object instead of the swapped object.
>

Well it doesn't *have* to, when we change the value of an object and
hence changing it's #hash value we already have the idiom that sets and
dicts need to be rehashed to accommodate for this. So naive as I am I
find the current behavior more surprising than if some users of become:
would also do a rehash.

R
-

Reinout Heeck-2

Re: identityHash and become: question

In reply to this post by Vassili Bykov

Vassili Bykov wrote:
> but this:
>
> anIdSet includes: foo
>
> will be false with probability very close to 1, unless #become: also
> takes care to find each identity-hashed collection the receiver or the
> argument are elements/keys of and rehash it.

Like I wrote elsethread I would have been less surprised if this was
exactly what was done...

I don't want to drag discussion on needlessly , but I do want to
emphasize I learned something new that I could have learned years ago if
it would have been included in the comment of #identityHash.

Could you please consider creating an AR for that, since this behavior
is not clearly visible in the image unless it is pointed out.

Thanks!

Reinout
-------

ICS.Manz

Re: identityHash and become: question

In reply to this post by Roel Wuyts

It seems we have two different expectations for the behaviour of become:

1.) become: is swapping two objects
2.) become: is shape shifting two objects

Let's look at an example to illustrate what I mean:
Tom and Jerry are two animals in a zoo.
Tom is in cage1 and Jerry is in cage2.
Tom is a mouse and Jerry is a cat.
They are of different kind and exhibit different behaviour.
The visitors of the zoo look at one cage a time.

A magician shouts: "Tom become: Jerry!".
All gets dark for a minute and there is some rustling.

Afterwards there is light again and now
cage1 contains a cat that looks like Jerry and behaves like Jerry,
cage2 contains a mouse that looks like Tom and behaves like Tom.

But what happened behind the scenes?

Did Tom and Jerry change their cages?
That would be swapping version (1).
Or was the magician so good that it is still Tom in cage1
and Jerry in cage2? But both were turned in the other animal?

If we could ask them they would tell us.
I think you guessed it: The names are the identity hashes.

It seems that the current implementation of become:
prefers the shape shifting version (2).

--
Well, I hope this little scenario helps in the further discussion
on what identityHash and become: should provide.
--

Best regards

Traude Manz
ICS AG

Vassili Bykov

Re: identityHash and become: question

[hidden email] wrote:

> It seems we have two different expectations for the behaviour of become:
>
> 1.) become: is swapping two objects
> 2.) become: is shape shifting two objects
>
> Let's look at an example to illustrate what I mean:
> Tom and Jerry are two animals in a zoo.
> Tom is in cage1 and Jerry is in cage2.
> Tom is a mouse and Jerry is a cat.
> They are of different kind and exhibit different behaviour.
> The visitors of the zoo look at one cage a time.
>
> A magician shouts: "Tom become: Jerry!".
> All gets dark for a minute and there is some rustling.

That must be the sound of direct references replaced throughout the
object memory. The magician should consider using indirection through
object headers or forwarding thunks, then he'd be done in much less than
a minute.

> Afterwards there is light again and now
> cage1 contains a cat that looks like Jerry and behaves like Jerry,
> cage2 contains a mouse that looks like Tom and behaves like Tom.
>
> But what happened behind the scenes?
>
> Did Tom and Jerry change their cages?
> That would be swapping version (1).
> Or was the magician so good that it is still Tom in cage1
> and Jerry in cage2? But both were turned in the other animal?

But what does it mean that something that looks like Tom and thinks and
behaves like Tom is "still" Jerry? As far as anyone--including the
alleged Tom--is concerned, he *is* Tom.

> If we could ask them they would tell us.
> I think you guessed it: The names are the identity hashes.

They would tell if they could speak. But not all animals can, so we have
to go by the signs on the cages.

Identity hashes are not names; they are signs "1" and "2" hanging on the
cages. Long ago in that zoo they decided to always keep animals in cages
(there once was a horrible accident and people still talk about dangling
references). Any interaction with any animal is now only allowed through
a cage.

When the magician does his become: trick, Jerry really does change
places with Tom. "Really" in the sense that Tom is teleported into
Jerry's cage and Jerry--into Tom's. But the signs on the cages stay put
because moving them around would confuse the zoo keepers. Unfortunately
for Jerry who got moved to cage 1 just before the feeding time for
even-numbered cages.

>
>
> Best regards
>
> Traude Manz
> ICS AG
>
>

--
Vassili Bykov <[hidden email]>

[:s | s, s printString] value: '[s: | s, s printString] value: '