David Griswold wrote:

> I made a clear argument that all programs in Smalltalk (or in any
> imperative language for that matter) have a universal, *implied* constraint
> that you shouldn't change objects that are being used by something that
> assumes that they remain the same.  This language-wide constraint clearly
> excludes (x removeAll: x), and the specification for removeAll: doesn't
> override that.

and

> Programmers should read this additional constraint into all ANSI
> specifications, so that removeAll: has the implied language "the argument
> can be any collection that is invariant during the execution of this
> method".

(x removeAll: x) will NOT change x during its own execution of the part which
relies on x being invariant, IF IMPLEMENTED PROPERLY.

=> There is NO violation on principle of the mentioned language-wide constraint
by (x removeAll: x). This differs from the iterator-methods with blocks where it
can NOT be guaranteed for ALL possible pieces of code in the block, that this
constraint will not be violated, whereas #removeAll: can be implemented with the
guaranty to work correctly with ALL possible arguments.

=> Therefore there is also no reason to assume that (x removeAll: x) is
violating / has to violate this language-wide constraint. Such an assumption may
stem from the current wrong implementation or from 'analogous' thinking of
changing a collection while iterating over it, but it has no validity, meaning
no programmer has to make such an assumption.

=> Therefore (a removeAll: b) can and should handle perfectly well a == b
without raising an exception, which itself has to be considered introducing a
new error because it stops the program when the programmer has all rights to
expect the opposite.


Some had the abstract argument of not to change the semantics of Collection:

Changing #removeAll: in the proposed way would not change semantics of
Collection, it would extend them, so that they stay completely compatible with
existing semantics. There will be no confused programmer and no program becoming
buggy. The programmer can ignore the ability of (a #removeAll: b) to handle
a == b, explicitly test on identity and write the code which could be written
once inside the method many times outside of it.

But that would be the opposite of what the inventors of Smalltalk had in mind
when creating the paradigm 'everything is a method' which allows for high
reusability.

The core system should be as universal, elegant and mighty as possible. If a
change in this direction is possible without breaking anything, we should
certainly make it.

The whole Squeak system is work in progress - many parts of it are improvised
or experimental - preserving the history of some other parts up to the smallest
detail under nearly all circumstances would be funny.  

Furthermore I find it difficult to call something semantics which is at least a
programmers trap, and as I showed above is - IMO - a real error.

One last thought:
May it be that some opinions and ideas in this thread have their subliminal
roots only in a counter reaction to some specific person's destructive dialog
mode which I would characterize as a bulldozer coming from all sides tearing
each sentence of all others to pieces?

regards,
Martin