Fwd: [squeak-dev] DictionaryIntegrityTest >> #testDictionaries failure

Eliot Miranda eliot.miranda at gmail.com
Tue May 14 17:43:01 UTC 2013


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.



> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130514/fe641def/attachment.htm


More information about the Squeak-dev mailing list