David Farber <dfarber at numenor.com> is claimed by the authorities to have written:

>
> 1. Make the code work.
> 2. Make the code work /right/.
> 3. Make the code work /fast/.
>
Cool! Somebody that knows Rowledge's Rule. I used to teach this approach
fifteen years or so ago. Obviously, not to enough people (yet).

I'm pretty sure sure it is impossible to _guarantee_ safety when
iterating over collections. After all, a #do: can range from
	do:[:el| mycount _ mycount +1]
to
	do:[:el| self transmit: el bySnailMailTo: fred
andRemoveThreeRandomElementsFrom: self during: [1 to: SmallInteger
maxVal do:[fred workDestructiveEvilUpon: self]]

However, I'm equally sure we can improve things markedly. There are
loads of places where code fails silently or with some meaningless
error. There should be many fewer.

#removeAll: and #addAll: (et al.) need to consider boundary conditions
and at the very least document where they will fail and how. We have to
consider what _ought_ to happen when somebody does x removeAll: x - at
the least I'd hope for a signal to tell me it is a problem. If it can't
be made to work 'properly' let's try to make it let us know in a
sensible manner. I have trouble imagining that it wil massively impact
performance in cases such as #removeAll: since they are not exactly
common messages.

It's my old friend Pareto at work again; if you can improve things for
some cases without damaging others, it's a no-brainer. Do it.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Strong, like bull.  Smart, like tractor.  Beautiful, like KV-2. (A WWII era Russian tank.)