Thank you, John! Your explanation was a big help.

I didn't have to deal with object identity issues in Smalltalk/V (VSE),
which was the last system I used, so I don't know how it would have handled
'abc' == 'abc'. Thankfully, Squeak handles this the "right" way! But
nonetheless, this discussion is helping me visualize what is going on behind
the scenes.

So it's best just to think of Smalltalk variables as object references, not
as value holders. And, for example, when a method gets an object as an
argument, the method's variable is a reference to the object (pass by
reference). Am I on track here?

Thanks again,

Chris


-----Original Message-----
From:	squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of John M
McIntosh
Sent:	Saturday, March 23, 2002 2:53 AM
To:	squeak-dev at lists.squeakfoundation.org
Subject:	RE: Object pointers

>
>Basically, I'm trying to create relationships between objects using
>Association. But I became alarmed today when I did the following:
>
>assoc := Association new.
>
>aKey := 'keystring'.
>aValue := 'valuestring'.
>
>assoc key: aKey value: aValue.
>
>aValue := 'new value'.
>
>assoc value  ==>  'valuestring'
>
>This made me think that the association was storing a *copy* of aValue in
>its own instance.
>
>Exactly what is going on in this situation?
>

Well 'valuestring' is a instance of a String object floating about
referenced by  aKey and then via an instance var in assoc, so both
aKey and the instance var in assoc point to that string instance.
Unless of course assoc->key:value: makes a copy (doubtful).

When you change the reference aValue to point to the other string
object 'new value' that doesn't change the reference to 'valuestring'
because the instance var in the instance of assoc is still point to
it.

Now if you where to directly alter the string by manipulating aValue
that would have implications. (aKey at: 2 put: $x) then look at assoc
value

Of course when you remove all references to the 'valuestring' then it
will become garbage and be collected at some future point.

String constants need a bit of care, to ensure you don't alter them
and everyone else who refers to them, and of course string constants
that are the same within a method might have different behavior ie ==
depending on the flavor of Smalltalk you use. mmm for example 'abc'
== 'abc' might not be true since there could be two string objects
here depending on what the parser does. This only bites the unwary
and I think most current Smalltalk have worked around this issue. MMm
I think it was early versions of visualage that inflicted that gem on
us, no?
--
--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================