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

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Tue Sep 3 08:28:54 UTC 2002


Hi all!

"Andrew C. Greenberg" <werdna at mucow.com> wrote:
> On Monday, September 2, 2002, at 09:51 AM, Hans-Martin Mosner wrote:
> 
> > Looks to me like we would open another can of worms by relying on 
> > #copy semantics to get #removeAll: right.
> > Note that I do agree that using #copy would improve the behavior of 
> > #removeAll: in certain situations, but it just does not fix it for the 
> > general case - because IMO that's impossible.
> 
> This was, of course, my point.  Fixing a bug that might not be a bug to 
> introduce at least one bug that will certainly be a bug isn't the best 
> solution to this problem, particularly when the bug that might not be a 
> bug might not be a bug except in an obscure case where there isn't any 
> compelling need to fix the bug that might not be a bug.
> 
> Merely whining that a fundamental change to Collection is demanded 
> notwithstanding these problems because LinkedList isn't a "normal" 
> collection (which it isn't) is as silly as arguing that 
> ArraySliceCollection isn't yet a part of the core image.  We shouldn't 
> do it in the absence of a comprehensive overhaul (including a 
> determination that same is needed) -- we are simply opening worms 
> everywhere to fix a maybe-a-bug that may or may not need fixing.
> 
> Notwithstanding that, I am sensible to Richard's suggestion that when 
> it is practicable to catch a circumstance that misbehaves, we shouldn't 
> do so silently.  I am for adding the assert.

I can understand your points, but what about fixing the specific case by
calling removeAll instead?
And of course adding such a method as has been described.
AFAICT that would fix the "bug" too, give a real performance boost for
emptying collections and not introduce any other bugs.

The only (that I can remember right now) reason for not doing this (and
instead add an assert/signal) that I can understand would be the
(debatable) portability/ANSI-compliance issue. But if this discussion is
meant to be some form of precedent for how we should evolve these core
classes in Squeak from now on then it will mean we can't do any changes
unless they are:

1. Fully ANSI defined (and not just "defined depending on
interpretation" or "undefined" - both of these situations have been put
forward as cases where we simply should not get a go)
2. Fully portable to other dialects (which of course is impossible since
they too differ, but nevertheless)

(Do note that Squeak is NOT ANSI compliant in any way today - we haven't
even adopted the file open/creation methods (someone informed me)
defined in ANSI. And there are tons of other non ANSI stuff even in
classes like Collection, again #+ was mentioned etc.)

Personally I do NOT wish that Squeak follows ANSI without question. I
wouldn't mind trying to follow ANSI whenever it makes sense, and I
wouldn't mind having an ANSI Module that I could use if needed, but if
we simply say that the core classes simply stopped evolving with the
x3j20 then I think we are heading in the wrong direction.

I also do not wish Squeak to aim at portability without questioning the
merits of that. I DO like the fact that we try to mark stuff as ANSI or
portable or whatever as Richard has suggested though - that can never
hurt.

Anwyay, ff this is the view held by several people on this list then we
really need to ask us another question - how do we handle these
disagreements?

I suppose the new Modules system obviously gives us the breathing room
to handle this by simply saying that - hey, you want to have bleeding
edge Collection classes that don't care about ANSI or portability? Just
use Module "Squeak SuperCollections" instead of the ordinary
Collections.

This is all fine and dandy. But what Modules (if any) will be "blessed"
as base Squeak? Who will bless, the SqueakFoundation? And how do we
handle "configuration maps" - different base setups of Squeak?

Now I drifted off into Modules again, but this discussion really begs
for some policy in this area IMHO.

regards, Göran



More information about the Squeak-dev mailing list