Tim, you're apparently not reading my posts very carefully because everything you're responding to are things I specifically dealt with.
I didn't say that collections should be copied before iterating over them. I specifically said that such copies are too expensive.
I didn't say that collections should be locked while iterating over them, I only said that it doesn't make sense to expect iterators to change their behavior mid-stream if you try to mutate collection out from under them - that this was too much to ask, just like implicit copying was too much to ask.
I didn't say that I wanted arrays locked in a specific memory location while iterating over them, I specifically said that allowing the GC to move them was not onerous as long as there's some way for Slang code to keep track of where the array is.
As for being lectured about how I don't know enough about garbage collectors. Well that would be true if I had said any of what you assumed I was saying... Actually I know enough about GCs.
Is my writing that hard to understand?
I'd respond to what you said about become: inside of iterators, but I'm not getting the impression that you read what I said about become: any more carefully than you read what I said about iterator primitives. You certainly didn't respond to a single idea I stated...
Ah well, I try anyway: Here's a new idea about "become:" "become:" has such drastic effects that no method can run properly if it's owner is changed by "become:" unless it was designed or vetted for that specific change. No iterator in Squeak was designed to handle it's object being changed out from under it - so they will exhibit various bugs - bugs that would be different if trivial internals of those method were changed slightly - arbitrary bugs. Your example tells me nothing about become: becaue it isn't proper useage of become:.
As for multitasking examples - that's something else a program has to be specifically designed to handle in all of it's parts... Once again, the iterators weren't designed to have their objects changed out from under them by multithreaded programs - so they don't handle it in any reasonable way, and will exhibit bugs.
If you want to propose redesigns of every iterator to handle these things go ahead. BUT IT'S NOT A FLAW IN MY PROPOSAL THAT IT DOESN'T MAKE THE CODE HANDLE CASES THAT IT ALREADY CAN'T HANDLE.
Joshua Scholar