[BUG]Collection>>removeAll:
Tom Rushworth
squeak-dev at lists.squeakfoundation.org
Tue Sep 3 03:03:21 UTC 2002
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
More information about the Squeak-dev
mailing list
|