(Environment named: #Smalltalk) trap in 4.5

While working on serialization of objects referencing the new
"Smalltalk globals," (now an Environment), I came across an apparent
issue with our 4.5 release image.  The Smalltalk Environment is at
String-key 'Smalltalk' of its 'Instances' IdentityDictionary.

So we have no way to access (Environment named: 'Smalltalk') or
(Environment named: #Smalltalk) without inadvertently creating a new
Environment with that name.

Both the key and the Smalltalk Environment currently have String's for
the name, but #environmentNamed: assumes the argument is a Symbol.
Could we choose to consistently use either Strings or Symbols
exclusively?

Either way, I would like to convert the 'Instances' global to a
regular Dictionary instead of a IdentityDictionary.  If we end up
deciding to use Symbol names, then logical #= (which defaults to #==
in Object anyway) works whereas if we use Strings, it will work too.

On 01.05.2014, at 22:46, Chris Muller <[hidden email]> wrote:
I'd vote for Symbols and _keeping_ the IdentityDictionary

best
        -tobias

> I'd vote for Symbols and _keeping_ the IdentityDictionary

May I ask why?

On 01.05.2014, at 23:14, Chris Muller <[hidden email]> wrote:

>> I'd vote for Symbols and _keeping_ the IdentityDictionary
>
> 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.
And I think, when using symbols, IdentityDictionary comes naturally.

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!

On 5/1/14, Tobias Pape <[hidden email]> wrote:
+1
>
> 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!
>

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

Hi and sorry for the late reply

On 02.05.2014, at 18:06, Chris Muller <[hidden email]> wrote:
No, I would use an indexable structure like an array or possibly
an ordered collection.
It shouldn't. This, however, depends on the proxy implementation (what
about a vm-supported one, like Rackets impersonators/chaperones[1] although
these do not compare identity, either).

I think either proxies or IdentityDicts w/ Symbols should be used sparingly.
In both cases there are typically better designs available or conceivable.
  The Namespacing thing for one, I wouldn't consider typical and would think
that Symbols and IdentityDicts are appropriate here.
I think that in Smalltalk, Dictionaries are typically out of place anyway.
It is about an applications design.
        A dict is but a poor mans object.
And we can do typically better than that, like using actual, structured
objects.
  Here's a counterexample: In SqueakSource3, all  “model” objects (like
Projects or Members) have a “properties” dict that acts as extended
instance variables for things that are not always there (depending on the
features required).
  These properties are looked up with a symbol and the dict is
an idDict (on Squeakish) and a speicalized symbol-as-key dictionary on
gemstone. But the only reason here to do it that way is to avoid hacky
tricks to get inst-vars on-the-fly. Moreover, these objects have
Magritte-descriptions, so that a possible user, like another Database
Driver can get enough information about an object without actually requiring
it to expose the dict it uses.

> […]

Best
        -Tobias


[1]: http://docs.racket-lang.org/reference/chaperones.html

On 18.05.2014, at 22:51, Tobias Pape <[hidden email]> wrote:
Correction: I misread you question.
I would probably go for an indirect addressing, possibly with
a sparse array as first thing.
  I dislike numbers as keys for either Dicts or identity dicts.

[…]

Best
        -Tobias