On Tue, 14 May 2013, Eliot Miranda wrote:

> 
> 
> On Tue, May 14, 2013 at 10:39 AM, Chris Muller <asqueaker at gmail.com> wrote:
>       My question is:  Should users of Dictionary regard the internal
>       Associations as private, internal and, otherwise, not to be messed
>       with?
>
>       VisualAge had a class called a LookupTable which was identical to a
>       Dictionary but by using... parallel keys/values Arrays I think, and so
>       while it could answer an #associationAt:, it would just be a new
>       object and not part of the Dictionary.  To think one could set the key
>       of this Association would not allow compatibility with regular
>       Dictionary.
>
>       So I personally have always regarded the internal Associations as private..
> 
> 
> They clearly are not in important circumstances.  One is global variables (system, pool and class), where the association is the variable.  There are other circumstances (WeakDictionary) where they are
> private and carefully managed.  MethodDictionary, IdentityDictionary etc are like VA's LookupTable; they have no associations.

In Squeak only MethodDictionaries use two arrays internally. Actually they 
only use one array, the keys are stored in the MethodDictionary object's 
variable slots. That's how they can have the same layout as other 
Dictionaries.


Levente

> 
> 
>
>       On Tue, May 14, 2013 at 11:01 AM, Bob Arning <arning315 at comcast.net> wrote:
>       > It's not clear what you are asking. Dictionaries have long had methods like
>       > #associationAt:. One would want to be careful using such methods, but they
>       > do seem to be *public*, however fuzzy that distinction might be.
>       >
>       > Cheers,
>       > Bob
>       >
>       > On 5/14/13 11:42 AM, Chris Muller wrote:
>       >
>       > It's enough to change the key of the association to a different object.
>       >
>       > True but that would be circumventing the public API of the Dictionary
>       > would it not?  Is there any path through the API where one obtains
>       > such access to the underlying Associations?
>       >
>       >
>       >
>       >
>       >
>       >
> 
> 
> 
> 
> --
> best,Eliot
> 
>