Re: [BUG]Collection>>removeAll:

Martin Wirblat <mw.projanynet@xxxxxxxxxxxx> wrote:
> Subject: Re: [BUG]Collection>>removeAll:
> To: Squeak <squeak-dev@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> Date: Thu, 29 Aug 2002 18:09:01 +0100
> Reply-To: squeak-dev@xxxxxxxxxxxxxxxxxxxxxxxxxx
>
> 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