[Cuis-dev] Dictionary

Jonathan Kelly jonkelly at fastmail.fm
Thu Dec 31 16:47:01 CST 2015

On 01-Jan-16 6:47 AM, Phil (list) via Cuis-dev wrote:
> On Thu, 2015-12-31 at 13:38 -0500, Dan Norton via Cuis-dev wrote:
>> On 30 Dec 2015 at 23:58, Phil (list) via Cuis-dev wrote:
>>> Hi Jonathan,
>>> On Thu, 2015-12-31 at 14:23 +1100, Jonathan Kelly via Cuis-dev
>>> wrote:
>>>> Hi All,
>>>> I'm a relative newbie to Smalltalk, having dabbled in the past,
>>> but
>>>> have
>>>> decided to get into it proper for some projects I have in mind.
>>>> So, I've written the code for BTree as a learning  exercise and
>>> was
>>>> thinking about the Interface and thought Dictionary would be a
>>>> natural
>>>> protocol to follow. Heavens - they think someone can understand
>>> all
>>>> this
>>>> at once?  Funny they never say how much effort that would take,
>>> or
>>>> what
>>>> your IQ would have to be.  I guess that's just me being
>>> overwhelmed.
>>> Heh, yes... it can take some getting used to being exposed to
>>> every
>>> class and method w/ source and little guidance vs. the more
>>> conventional languages/libraries where they pretty much say 'do it
>>> this
>>> way'
>>>> Anyway, I discovered what I would say was a nightmare waiting to
>>>> happen
>>>> .. for someone, but it would seem not, as I'm assuming that code
>>> for
>>>> Dictionary>>add: has been around for along time. Interested to
>>> hear
>>>> more
>>>> experienced smalltalk-er views.
>>>>> aDict assocA assocB |
>>>> aDict := Dictionary new.
>>>> assocA := 'A' -> 123.
>>>> assocA printString. "'A' -> 123"
>>>> aDict add: assocA.
>>>> assocB := 'A' -> 456.
>>>> aDict add: assocB.
>>>> assocA printString. "'A' -> 456"
>>> I would highly recommend not adding associations directly as that's
>>> an
>>> exposed implementation detail that may change (and has in the
>>> past... I
>>> seem to recall a method to add associations that was used in
>>> several
>>> places being removed)  Probably safer to do something along the
>>> lines
>>> of:  aDict at: 'A' put: 123.
>>> Beyond that, are you wondering why your 123 was replaced by 456?
>>>   If
>>> so, it's because the test used by Dictionary is equality (i.e.
>>> 'A'='A'
>>> even if they are two different instances of the string 'A') rather
>>> than
>>> identity (i.e. testing for the same object)  There are very few
>>> places
>>> in Smalltalk where you will see object identity used that way and
>>> it
>>> is
>>> generally discouraged unless absolutely necessary.  If what you
>>> really,
>>> really wanted to be used is an identity test there is always...
>>> wait
>>> for it... IdentityDictionary :-)
>>>> Jonathan.
>>> Phil
>> Hmm. I'd like to understand this better. Let's take the dictionary
>> out of the picture temporarily
>> and expand the number of variables to assocA, assocB, assocC,...,
>> assocG or whatever.
>> These variables can be assigned unique associations of 'A'. They can
>> be reassigned at will
>> and a change to one does not affect another. Now let's reintroduce
>> the dictionary:
>> aDict add: assocG.  "the first add seems OK"
>> aDict add: assocA.  "changes the dictionary AND assocG, the last
>> added"
>> The other variables are unaffected. Why is this change to assocG not
>> a bug?
> An Association is just an implementation detail (i.e. the storage
> mechanism the Dictionary uses), all the Dictionary promises to do is
> store an arbitrary object given a distinct key value (as determined by
> #=), not distinct Associations.  It doesn't promise to use the
> Association, or even the key, you pass it.  This is actually what most
> people want it do do the majority of the time.  If what you need is
> distinctiveness test to be based on the key identity, then you use
> IdentityDictionary (which uses #==)  If you look at #scanFor: in both
> *Dictionary classes you'll see the difference and notice that neither
> one cares about the Association, only its key.  If what you are looking
> for is a collection of unique associations, then what you probably want
> to use is an IdentitySet for your associations.
>>   - Dan
>> _______________________________________________
>> Cuis-dev mailing list
>> Cuis-dev at cuis-smalltalk.org
>> http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.or
>> g
> _______________________________________________
> Cuis-dev mailing list
> Cuis-dev at cuis-smalltalk.org
> http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org
Have you heard of the term "defensive programming"?

You've made a case, but how would anyone know that is the intended 
(devalued) usage of Associations?

Here's my case to the contrary:
LookupKey : I represent a key for looking up entries in a data 
structure. Subclasses of me, such as Association, typically represent 
dictionary entries.
Association: I represent a pair of associated objects--a key and a 
value. My instances can serve as entries in a dictionary.
Dictionary: I represent a set of elements that can be viewed from one of 
two perspectives: a set of associations, or a container of values that 
are externally named where the name can be any object that responds to 
=. The external name is referred to as the key.  I inherit many 
operations from Set.

(Dictionary) add: is in the "adding" category - not "private". There is 
no warning against it's usage that I can see.

(Object) -> anObject
     "Answer an Association between self and anObject"

... would seem to imply that an Association is something more than an 
implementation detail.

Oh, I don't have a usage ... I was looking at the code trying to 
understand the Dictionary protocol and saw something that looked wrong 
because I've had my head in BTrees for a few weeks.

I'm happy (well not really) to programme by agreement, but please, you 
have to let me know what the agreements are! :)


More information about the Cuis-dev mailing list