From: jeff@is.s.u-tokyo.ac.jp (Jeff McAffer)
Subject: Re: Collection>>addAll: problems on Dictionaries
Reply-To: jeff@is.s.u-tokyo.ac.jp
Organization: Dept. of Infomation Science, University of Tokyo.
Date: Sun, 26 Jul 1992 07:28:58 GMT

In article <HUGGINS.92Jul25161931@dino.ti.com> huggins@ticipa.pac.sc.ti.com (Gray Huggins) writes:

 >An interesting question has come up about the proper behavior of 
 >Collection>>addAll: when used on a Dictionary in Smalltalk 80.  As
 >inhierited, addAll: when sent to a Dictionary will only work if passed
 >a collection of Associations.  (A condition which is not checked for,
 >thus anything else will get a "does not understand key:")
 >
 >Does it make sense to you to "add all" of a Dictionary to a Dictionary?

Yup, I think that makes sense.  However, I could accept protocol that
would also accept collection of key/value *pairs* (not necessarily
Associations).

{ deleted stuff }

 >simply use associationsDo: instead of do:.  No, the real debate
 >centered around what Dictionary contains.
 >
 >Is it a collection of values that happen to be keyed, in which case
 >the values are of prime interest.  Or is it a collection of
 >Associations, in which case the key/value pair is of prime interest.

To consider this question properly I think we have to separate ourself
from the way dictionaries are implemented and the way people tend to
think of them (since as you mention, everyone knows (thinks!, more on
that later) they are implemented with Associations)

Personally, I think that the identity of associations in dictionaries
should NOT be assumed.  This would seem to be the real crux of the
matter.  I know that this would cause problems with current uses but
current uses are based on an inconsistent design.  If you want
identical association dictionaries then just use IdentitySets and add:
associations.  Perhaps change the protocol a bit to suit the new role.
For example, at:put: would be syntactic sugar for add: anAssociation
and would return the association in which the value and key were
stored.

 >I have never been real fond of the fact that the implementation of
 >Dictionary is soooo public.  (Everyone knows it's done with
 >Associations).  But that fact is not going to change.  (Which might

Not all dictionaries are implemented with Associations.
IdentityDictionaries for example are implemented typically with
coincidental Array structures.  Their protocol is roughly equivalent
to that of Dictionaries.  This shows that a dictionary which does not
assume Association identity may be useful.  

Sadly, if you look at IDs in 80 and V you will notice some differences
and fun inconsistencies. (just for kicks try the following in V)

    | dict |
    dict := IdentityDictionary.
    1 to: 1000 do: [:i | dict at: String new put: i].
    ^dict keys

In summary, I think that dictionaries are collections of elements that
just happen to be indexed by arbitrary objects.  (you will often find
them lumped in with indexable collections in abstract descriptions)

 >server to agrue that Dictionaries by design are collections of
 >Associations!)

Yes, but the inclusion and role of methods like includesAssociation:
vs. includes: would indicate the opposite and show that at the very
least Dictionaries are inconsistent.  Why is it not includes: and
includesValue:?

--
atode, |m         -- Rockin' tunes empty my head and fill my soul!
                     Art!!  Is that you in there?!