Just to add a little fuel to the fire :)....

On Wed, Aug 28, 2002 at 02:24:49PM -0400, Andrew C. Greenberg wrote:
> On Wednesday, August 28, 2002, at 06:12 AM, goran.hultgren at bluefish.se 
> wrote:
>
[snip]
> 
> > - Creating a new collection does not retain identity.
> 
> Yes, this is the reason why it is valuable to have a method to remove 
> all elements in some cases.  It does not suggest that an implicit 
> iteration method should break Smalltalk's "don't change the iterating 
> collection" semantics rule for just a few special cases.

Think about the words "implicit iteration" with respect to "removeAll:".

I'm a newcomer to squeak, but I've been programming for a living since
the mid seventies.  When I see "removeAll:" the only way I can get to
"iteration" is to violate the modularity of the "removeAll:" method.

  - If I look inside the method and see the iteration and then make
    a decision based on knowing "removeAll:" iterates then I've thrown
    modularity out the window.

  - If I practice good modularity and don't look inside the method,
    and in fact deliberately "forget" anything about how "removeAll:"
    is implemented, then I can't make any argument about what it
    should do based on it "implicitly iterating".

If the method was named "iterativelyRemoveAll:" then I could buy your
argument:).  Since it isn't, modularity says not only that we shouldn't
know that "removeAll:" iterates, but that we should make no effort to
know and that we should have no expectation one way or the other that
it does or does not iterate.

-- 
Tom Rushworth