Philosophical: why is there no Collection>>removeAll

Hi...

A happy new year to everybody!

Chris Uppal asked this quite a while ago and got no answer:
>I have never understood why there is no standard operation for emptying
>Collections; it is, after all, hardly an obscure operation.
>Blair, would adding #removeAll (selector chosen to avoid the ambiguity of,
say,
>#clear or  #empty, which could be tests rather than operations) be an undue
>"fattening" of the Collections interface ?

As I also always am surprised when typing myCollection removeAll and it does
not work, I am asking again:
Is there any philosophical reason for not supporting this method?

(The only reason I can think of is that it does not work for Arrays, but
this is  hardly a valid one as e.g. removeAll: aCollection does not work,
either).

Ciao

...Jochen

In VisualWorks (7.1), sending #removeAll: with the collection itself as the
argument seems to work. The collection itself is modified to include no
elements.

It is considered good practice to keep collections private. Access outside
the class to the collection should go through a "Collection Accessor Method"
(Kent Beck, Smalltalk Best Practice Patters, page 96). If you follow this
pattern, you can empty the collection by setting the instance variable
holding the collection to a new (empty) collection. As no other objects
should hold on to the old collection this will work ok.

I guess the need for #removeAll is not really needed. You can choose one of
the two methods described above. Personally I would avoid the problem by
using "Collection Accessor Method".

Runar Jordahl
[hidden email] (Remove the letter -->z<--)

Runar Jordahl wrote:

> I guess the need for #removeAll is not really needed. You can choose one
> of the two methods described above. Personally I would avoid the problem
> by using "Collection Accessor Method".

By the same argument, there is no need for any #remove* methods on Collection.

    -- chris

> By the same argument, there is no need for any #remove* methods on
Collection.

That's why I have put the prefix "philosophical" ;-)

Ciao

...Jochen

Chris Uppal wrote:
> Runar Jordahl wrote:
>
>
>>I guess the need for #removeAll is not really needed. You can choose one
>>of the two methods described above. Personally I would avoid the problem
>>by using "Collection Accessor Method".
>
>
> By the same argument, there is no need for any #remove* methods on Collection.

That's not entirely true. You need a means to remove an element,
otherwise you'd have to create a new collection and do a select/reject
every time you want to remove one or some elements.

What Runar (and Kent) suggests is that you should not be able to remove
all items from a collection if you are not the holder of the collection.
It is always better to have a pair of addStuff: and removeStuff: methods
on the collection holder object which adds and removes elements.

I think it is even faster to simply replace a collection with a new one
if you want it to hold none of the objects any more. This should also be
put in a method of the holder.

Joachim

> What Runar (and Kent) suggests is that you should not be able to remove
> all items from a collection if you are not the holder of the collection.
> It is always better to have a pair of addStuff: and removeStuff: methods
> on the collection holder object which adds and removes elements.

I agree, but as you say, the addStuff:, removeStuff: is in the Collection
holder. IMO the collection holder himself should be able to remove all
elements easily.

> I think it is even faster to simply replace a collection with a new one
> if you want it to hold none of the objects any more.

The cost is not gone, but moved to the garbage collector, which now has to
resolve a more difficult object cluster. it may be faster, may be not.

> This should also be put in a method of the holder.

Now I am completely confused. If you put it into the holder, you do not gain
anything, as this enables outsider objects to effectively delete everything
(exactly what was claimed to be not a method to be available " if you are
not the holder of the collection.").

My main reason for havin removeAll is, that it is just more natural and also
readability is improved if you write:
myCollection removeAll.
rather than
myCollection := OrderedCollection new.

My INTENTION is to removeAll elements and not to create a new one, so the
first is intention revealing, the second not.

Ciao

...Jochen

Joachim Tuchel wrote:

> > By the same argument, there is no need for any #remove* methods on
> > Collection.
>
> That's not entirely true. You need a means to remove an element,
> otherwise you'd have to create a new collection and do a select/reject
> every time you want to remove one or some elements.

Yes, that's *exactly* my point.


> What Runar (and Kent) suggests is that you should not be able to remove
> all items from a collection if you are not the holder of the collection.
> It is always better to have a pair of addStuff: and removeStuff: methods
> on the collection holder object which adds and removes elements.

I think this is a red-herring, that the distinction between "holder" and
"non-holder" is irrelevant here.  So let's restrict our attention only to code
in the "holder".  Why can it remove all elements one-by-one but not all at once
?

In any case, I don't see that a "religious" view of how I "ought to" structure
my code has (or can have) any bearing on whether the Collections API is
well-designed or complete.  The two topics are at different levels of
abstraction.


> I think it is even faster to simply replace a collection with a new one
> if you want it to hold none of the objects any more.

That may be true in many cases, but it's not going to be a huge difference
(compared with a properly implemented #removeAll), and its rarely going to be
worthwhile to sacrifice clarity and naturalness of expression in order to gain
a small increment in speed.

    -- chris