Tim -- What is wrong with the semantics of copying a collection before you iterate over it? If that was how do: were implemented, how would 

	do:[:el| self transmit: el bySnailMailTo: fred
andRemoveThreeRandomElementsFrom: self during: [1 to: SmallInteger
maxVal do:[fred workDestructiveEvilUpon: self]]

be problematic? Ok, sure, the logic of the entire operation isn't any easier to follow, but its no longer do:'s fault. In fact, with copy-before-iterate semantics, it should be straightforward (albeit tedious, and therefore still error-prone) to figure out what your monstrous do: would, in fact, do (without, of course, having to actually /run/ the dang thing).

So do you (or does anyone else) have a problem with the /semantics/ of copy-before-iterate--or is the issue just that the naive implementation of actually copying the entire collection is too slow?

If speed (not semantics) is the issue, then what about doing something more sophisticated than brute copying. For instance: a quick glance through the OrderedCollection methods leads me to believe that all state-changing operations on an OrderedCollection get routed through (or /could/ get routed through) insert:before and removeIndex:. Just two methods. So now, what if we changed those two methods to only /log/ the requested change if we are in the midst of an iteration. Once the iteration was finished we could process the log of operations.

Bye-bye speed (and space) hit of brute copying. Now, its true that we /could/ incur a space hit, but in cases where the collection /isn't/ being modified during iteration (which is surely the majority of cases) we shouldn't incur a space hit either ('cause there are no changes to log). The case where you have a large collection and are doing lots of munging of the collection while iterating should be sufficiently rare that you either don't mind taking the space hit or fall back to the current no-copy semantics or you rewrite the algorithm all together.

(Aside: It should be possible to fall back to the current no-copy semantics. I can think of cases where well controlled munging of the collection during iteration is desireable--but those cases are rare and require me conciously put aside my natural copy-before-iterate intuition.)

Would that work?

david


At 01:25 PM 8/22/2002 -0700, you wrote:
>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.)
>
>
>
--
David Farber
dfarber at numenor.com