Hi.  First, let me say, I really enjoy learning from you and sharing
my own limited knowledge whenever I can (that's why we're here!  :).
I'm not interested in "winning," I want Squeak to win.  If Colin
responds, I will do whatever he wants.  But we need to do _something_
because the image is pretty broken -- I am now finding CompiledMethods
with the wrong literal Global instances of Smalltalk=>Smalltalk in my
image (argh!).

>> May I ask why?
>
> Gut feeling, primarily.
> First, I think symbols are the right thing to identify Environments, I think.
> They are symbolic representers (is this a word) for their namespaces.

Yes, I think using Symbols for names of Smalltalk elements (class
names, method selectors, and Environment names) is totally
appropriate.  :)

> And I think, when using symbols, IdentityDictionary comes naturally.

I'm interested in your (and others') gut's thoughts on the choice of
an IdentityDictionary.

Let me ask you, if you needed to map what you _knew_ would be a bunch
of SmallIntegers in the range of SmallInteger minVal to SmallInteger
maxVal, since SmallIntgers are immediate too, would you also want to
use an IdentityDictionary?

Because, just reading this phrase:

         "when using symbols, IdentityDictionary comes naturally."

says that this is "matching up" a certain kind of input to go into a
certain kind of Dictionary, because you "know" that input will only be
Symbols.  Kind of like a static-typing on each end (but without the
safety!).  Like the SmallInteger example, it makes an
implementation-dependent coupling.  If I passed a Proxy to a Symbol to
look up an Environment, this implementation-dependency would cause it
to fail.

Wouldn't it be more in the spirit of OO to use a more-abstract
Dictionary and _delegate_ to the objects put into it about their place
and inclusion (hash and equivalency)?

Because, also, without sufficient incoming type-coercion, outside
users of the IDDictionary must "do the right thing" but, invariably,
one didn't, and the result is a lot more painful than it needed to be.

I must admit, my gut used to feel the same way as yours about this.
It wasn't until I developed a serializer and ODBMS that I realized
IdentityDictionary's are ONLY for when one is manipulating the
*physical* object-model in the image.  All other cases (certainly, a
logical lookup by name) should use regular logical Dictionary's
whenever they can, rather than physical IDDictionary's.

In any case, I guess we need appropriate type-coercion in #environmentNamed:.

Best,
  Chris

> Furthermore, I would avoid any strings (and if we must, have special
> selectors for them. (picking up your example:
> (Environment named: #Smalltalk) but
> (Environment namedFromString: 'Smalltalk')
>
>
> Best
>         -Tobias
>
> PS: It is frecking dangerous to have Symbols be actually Strings in disguise
>     once you want to do anything portable. I'm looking at you, class categories!
>
>
>