[BUG]Collection>>removeAll:
Martin Wirblat
mw.projanynet at SoftHome.net
Thu Aug 22 10:38:36 UTC 2002
Richard A. O'Keefe wrote:
> removeAll: aCollection
> |c|
>
> (c := aCollection) == self ifTrue: [c := c copy].
> c do: [:each | self remove: each].
> ^c
and
>> However, I will point out that the original comment, which I
>> pasted into my version of the method, indicated that the returned
>> collection should be the collection that was used as the argument
>> to #removeAll:.
>
> Absolutely right. However, there's an "except" hidden in there,
> "EXCEPT when aCollection == receiver", because the code doesn't
> actually make sense then.
The assumption that the identity of the collection does not matter,
and only the elements in it are important, is wrong.
I think in this case it is more or less the other way round.
1) the main properties of an object are its identity and behaviour,
instance variables are encapsulated, and only in well defined cases
they are accessable from the outside. Collections are clearly objects
where instances should be accessable, but this does not mean that
their identity is secondary.
2) many Smalltalk methods for basic access in ALL dialects return the
argument ( at:put: atAllPut: add: remove: addAll: removeAll: etc )
3) this way one can either choose to send the next message in a cascade
to the receiver object -> a add: b; nextMessage
or to the argument -> ( a add: b ) nextMessage.
I think this was the main intention for the existing definition, and
not to answer the removed elements
Answering a new collection in special cases and the same collection
in most cases would
1) potentially break tons of existing programs, and introduce hard to
find errors
2) make the protocol of basic access methods much more difficult
The more general rule is that the identity of the returned object
should in all cases be either a different one or the same as the
receiver/argument and at its best the message selector should give
the programmer a clue if the answer is a copy or the orignal.
regards, Martin
More information about the Squeak-dev
mailing list
|