Chris -- I ain't buying it. Are you really listening to what you are saying? "It's not practical to slow the whole system down to guard against this rare error condition." That's pure knee-jerk. Has anyone collected any performance stats on fixing removeAll:?

And stepping back to take a broader view, Richard has got me 100% convinced that it is time to fix the collection hierarchy so that iteration over collections is stable (i.e. conforms to /human/ intuition) even when you go mucking with the collection in the middle of the iteration.

Ralph, perhaps unwittingly, clinched it for me. He said, "To me, the definition of removeAll: is not an English description of what it does, it is

removeAll: aCollection
  aCollection do: [:each | self remove: each]"

Exactly. Only instead of "definition" I'd call the above my "mental model". Looks like it is Ralph's too. In fact, I bet it is many peoples' model. So what do we do when the code doesn't match the way we think? We /change/ the /code/!!

Ralph's quick experiement showed a 5%-20% slowdown in system performance if you just do the simplest thing that could possibly work: copy a collection before iterating over it. Fantastic. Sure, 5% is more than I'd like and 20% totally unacceptable, but we aren't /done/!

1. Make the code work.
2. Make the code work /right/.
3. Make the code work /fast/.

Given that we have solution that is right, now we just need to work on making it faster. Gee, isn't that the story of Smalltalk's life?

david


At 12:24 PM 8/22/2002 -0400, you wrote:
>[ I promised myself that I wouldn't re-enter the fray...  Another promise
>broken.  When will I learn not to promise the impossible? ]
>
>I've been thinking about this nit for a couple of days now, and I think that
>Martin Wirblat made excellent points -- please review his note, if you're of
>a mind to.  I agree with everything he wrote.
>
>Furthermore, I'd like to re-iterate what several people have now said.  It's
>not practical to slow the whole system down to guard against this rare error
>condition.  Proper bounds checking in this case is the responsibility of the
>sender.  I recommend updating the comment in the method to document the
>error condition and to leave the code unchanged.
>
>---==> Chris
>
>PS>  This has been an interesting discussion.  It's forced me to think a bit
>about an area that I've taken for granted for a long, long time.  :-)
>
>
--
David Farber
dfarber at numenor.com