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 |
In reply to this post by Chris Uppal-3
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 |
In reply to this post by jtuchel
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 |
Free forum by Nabble | Edit this page |