[BUG]Collection>>removeAll:
Stephan Rudlof
sr at evolgo.de
Wed Aug 28 08:30:30 UTC 2002
goran.hultgren at bluefish.se wrote:
> Tim Rowledge <tim at sumeru.stanford.edu> wrote:
>
>>"David Griswold" <David.Griswold at acm.org> is claimed by the authorities to have written:
<snipped>
>
>>> If you think that there is a need for a #removeAll method
>>>that performs that function, that is an arguable but separate
>>>discussion.
>>
>>A separate #removeAll for when you _know_ that you want to remove all
>>the elements already in a collection is almost nothing to do with the
>>real problem. The annoying problem is when you _unknowingly_ get screwed
>
>
> It isn't?
>
>
>>by an enumeration that messes with the collection itself. It is
>>trivially easy to imagine code that results in 'a removeAll: b' when a
>>== b because of other methods functions.
>
>
> Yep, and then the #removeAll would kick in which handles the case and we
> are all happy.
> Can't see your point. I mean IMHO all of these cases should run
> #removeAll :
>
> "x removeAll: y" (where x just so happens == y)
> "x removeAll: x" (of course)
> "x removeAll" (trivially)
>
> And because removeAll easily can be implemented as a special case in
> subclasses, as have been proposed for OrderedCollection as an example it
> would also be fast..
I see one real problem here, though: In VisualWorks? NonCommercial, Release
5i.1 the following does *not* work:
| coll |
coll := #(1 2 3) asOrderedCollection.
coll removeAll: coll.
coll
I think compatibility is important just here!
Introducing an assertion, which makes the implicit precondition explicit
though, doesn't hurt compatibility.
Greetings,
Stephan
>
>
>>Just because there is no total solution one should not assert that
>>nothing should be done to make small improvements.
>
>
> So true!
>
> Now... what about my proposal? :-)
>
> regards, Göran
>
>
--
Stephan Rudlof (sr at evolgo.de)
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3
More information about the Squeak-dev
mailing list
|