The standard does *not* support - a removeAll: a - [was: Re: [BUG] Collection>>removeAll:]

Andrew C. Greenberg squeak-dev at lists.squeakfoundation.org
Thu Sep 5 16:07:28 UTC 2002


On Thursday, September 5, 2002, at 01:37 AM, Richard A. O'Keefe wrote:

> 	It seems better to make it an error.
>
> This argument has the form
>     "Because a working method call can be replaced by code
>      that is obviously unlikely to work,
>      therefore the working method should be made to signal an error."
>
> I don't see any logic in that.

Of course not, but the illogic is in not in the message to which he was 
replying, but rather the proposed rebuttal of a straw man.

To restate the attacked argument in the form of a straw man addresses 
only weaknesses to the straw man.  Indeed, to reach the straw man, 
Richard's restatement reads the message to which he replies too 
literally, and with the assumption that the definition of #replaceAll: 
does not imply the supplied iteration after all, with the concommitant 
difficulty that the iterand should not be modified, hence reducing the 
debate to one of substitution of one implementation for another.

So what?  That assumption, that the ANSI and other definitions of 
#replaceAll: do not imply some sort of iteration over the parameter, is 
precisely the point he has purported to be proving.  Is it any suprise 
that from such an assumption, he can arrive at such a conclusion?

If one begins with the assumption that a presupposed conclusion is 
correct, is there any doubt but that by a chain of logic (or illogic) 
one can arrive at the same conclusion, however subtly restated?

Of course not.  While such "talk-reasoning" manifests impressive 
advocacy skills --Richard writes and argues well-- it doesn't actually 
prove anything one way or the other.  Richard must begin with the 
principles upon which we all agree, if he is to convince us of anything 
-- he should not begin with an argument of the form "I am right, 
therefore I am right (slightly restated)."




More information about the Squeak-dev mailing list