Martin Wirblat mw.projanynet@SoftHome.net wrote:
Subject: Re: [BUG]Collection>>removeAll: To: Squeak squeak-dev@lists.squeakfoundation.org Date: Thu, 29 Aug 2002 18:09:01 +0100 Reply-To: squeak-dev@lists.squeakfoundation.org
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.
Even if the method *can* be implemented to work correctly with all possible arguments (which I don't concede), that still doesn't mean that is what the current spec is. My whole point is that invariance assumptions are so universal in programs, that they have to be the default (i.e. arguments assumed invariant during method execution unless specified otherwise), otherwise any specification would become unreasonably overcomplicated. This effect is one of the main reasons why imperative languages are avoided whenever possible by anyone doing formal reasoning (including mathematics): otherwise their specifications would become wildly overcomplex because they can't assume invariance. I love Smalltalk, but it is imperative, so this is just one of the things you have to live with.
Therefore, the spec doesn't require that (x removeAll: x) be supported. Your argument seems to be that because this method might be able to be implemented without one form of the invariance assumption, then the spec must mean that. I don't see how that follows.
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.
You (along with some other people) are forgetting that specifications are not only for users, but for implementors. Extending semantics or generalizing functionality doesn't break user code, but it does break other implementations. And I would assert that Collection is the single most heavily reimplemented protocol in all of Smalltalk.
(Aside: as I have hinted before, Strongtalk's simple, elegant mixin model (which wouldn't be hard to add to Squeak) helps a lot with this problem, since then no one else would ever have to entirely implement the Collection protocol. This would allow new methods, like #removeAll, to be added with much less chance of breaking other implementations, since the new method would automatically propagate to other implementations. But even mixins don't automatically fix the breakage caused by changing the specification of an existing method like #removeAll:. )
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.
It all depends on what you think Squeak's purpose is. If it is just a limited-use multimedia etc. experiment, then you are right- hack away at Collection. If you think Squeak has any chance of someday becoming a widely-used Smalltalk implementation, it is a different matter. Personally, I think that the fact that Squeak is open source, portable, and based quite conservatively, all things considered, on standard Smalltalk semantics, as well as being written by people who know what they are doing, means that it has a chance to become a widely used system in the future. As the past manager of the production Java virtual-machine team, I can assure you that I have seen the real-world consequences of people hacking away freely on core software that they didn't think would be used widely, and it isn't pretty. Sorry if I assumed that the integrity of Squeak's core libraries was important.
Cheers, Dave
squeak-dev@lists.squeakfoundation.org