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
>>>> Hi All,
>>>> I'm a relative newbie to Smalltalk, having dabbled in the past,
>>>> 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
>>>> thinking about the Interface and thought Dictionary would be a
>>>> protocol to follow. Heavens - they think someone can understand
>>>> at once? Funny they never say how much effort that would take,
>>>> your IQ would have to be. I guess that's just me being
>>> Heh, yes... it can take some getting used to being exposed to
>>> class and method w/ source and little guidance vs. the more
>>> conventional languages/libraries where they pretty much say 'do it
>>>> Anyway, I discovered what I would say was a nightmare waiting to
>>>> .. for someone, but it would seem not, as I'm assuming that code
>>>> Dictionary>>add: has been around for along time. Interested to
>>>> 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
>>> exposed implementation detail that may change (and has in the
>>> past... I
>>> seem to recall a method to add associations that was used in
>>> places being removed) Probably safer to do something along the
>>> of: aDict at: 'A' put: 123.
>>> Beyond that, are you wondering why your 123 was replaced by 456?
>>> so, it's because the test used by Dictionary is equality (i.e.
>>> even if they are two different instances of the string 'A') rather
>>> identity (i.e. testing for the same object) There are very few
>>> in Smalltalk where you will see object identity used that way and
>>> generally discouraged unless absolutely necessary. If what you
>>> really wanted to be used is an identity test there is always...
>>> for it... IdentityDictionary :-)
>> 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
>> 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
> Cuis-dev mailing list
> Cuis-dev at 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
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
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