Proper way to empty a Dictionary..

From: Travis Griggs [mailto:[hidden email]]
Sent: Tuesday, July 25, 2006 8:00 PM
To: VW NC
Subject: Re: Proper way to empty a Dictionary..

It depends on what is wanted. Whether the client wants that dictionary to be empty (and thus any other observers of it to see it as empty), or just wants his own empty version. In the former case, the become: has the same semantic effects as your example. Anyway...

This got me to looking and thinking. Our BaseExtensions package has a removeAll method. It's a handy method; I'm surprised others aren't mentioning having a similar one. It's implemented naively and inefficiently as:

removeAll

          self removeAll: self copy

Dictionary and KeyedCollection both override at as you show

removeAll

          self keysDo: [:key | self removeKey: key].

I probably should add a SequenceableCollection variant that doesn't do the copy. I think I may throw all of them away though :)

Looking at Set(Dictionary), what's really tempting is to just do:

removeAll

          tally := 0.

This is VERY fast, and does indeed make the Set(or Dictionary) appear to be empty. For effective purposes, it no longer contains any elements. But stored in its memory, until some new add:(at:put:) overwrites the slot, the old object references still exist. This is most likely less desirable. Looking around even more, it would seem (to me) that the desirable and singular implementation would be:

Collection>>removeAll

          self become: (self copyEmpty: 0).

This is quite fast. Doing some timing tests, it's quicker than all of my implementations except for small collections with 2 or less elements. All of the other implementations are (N) variant, but this one has a fixed cost regardless of receiver size. By the time you get up to a Dictionary with 100 elements for example, it is about 10x faster. One drawback, is that you can do:

#(1 3 4 5) removeAll --> #()

which is not consistent with the fact that Array>>remove: is not supported. For consistency sake, one might argue that these should implement "shouldNotImplement" variants below. The original naive 'self removeAll: self copy' gets that as a side affect when it eventually gets to trying to send the remove:.

<rant aside>As for the use of the become: and the "don't use that" stuff. Well, first off, I'm Experienced(tm), so I get to use it. But seriously, I don't get why we as a "helping" community freak out everytime someone goes near that stuff? What's the message we're sending to Rick F? "Whatever you do, don't look at how the other collections change their size and do something like that! Ignore any lesson you might garner from looking at the source code! Read our docs instead! (hehe, extra points for bridging to another recent debate)."

It's not like this is C++ or something. Sometimes I wonder if we're jealous of the multitiered levels of ascension that mark the path to deeper C++ understanding and deification. So we carve out our own bit of "oo, tricky" stuff and exalt it. Ask yourself this, those of you that feel entitled to invoke the spells of become:, changeClassTo:, or utter the unforgivable verse "thisContext". Have you never just screwed up with one of these on your own? Or have you leveraged the use of them correctly since day one by following a rigid and structured catechism laid down by the early Kay-ites? I'm betting every Smalltalk guru out there who has effectively used these "deep" aspects of Smalltalk, learned the proper use of them through the school of hard knocks. I'm not suggesting Rick F. should or shouldn't make use of become:; but rather we try to avoid any sense of "pay no attention to that man behind the curtain."</rant aside>