Hi all!

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> > > > That's an interesting way to look at the situation, but do note that
> > > > most Smalltalkers will be suprised to find those assertions or
> > > > corrections in removeAll:.  Most fooAll: methods just do: on the
> > > > argument and foo: each element, and have no particular protection
> > > > against #foo: modifying the argument.
> > 
> > What is this last statement based on? Is it the Squeak image?
> > Using the MethodFinder and looking at all methods with "all:" I can
> > actually not find many methods that " just do: on the argument and foo:
> > each element"...
> > 
> > The only ones I found (a cursory look) where:
> > 
> > Collection>>addAll:
> > Collection>>removeAll:
> > CompositeEvent>>addAll:
> > POSimplePolygon>>addAll:
> > 
> > And I also found that OrderedCollection>>addAll: and
> > SortedCollection>>addAll: does NOT do that! Of course, what they do is
> > equivalent to "just do: and foo:" but it is still different code.
> > 
> > Further I found quite a lot of methods named "somethingAll:" but the
> > only thing I can see that they have in common is that they take an
> > argument that is intended to be a Collection of something. That is all.
> > 
> > > Which, of course, concedes the point that fooAll: methods entail an 
> > > implied iteration on its parameter.
> > 
> > Even if the statement was correct (which I do not agree with Lex, at
> > least not if we look at the image) it would only show that most such
> > methods where *implemented* that way. IMHO it doesn't "imply" anything.
> > 
> 
> I've been programming Smalltalk for a while, and I know what the
> implicitions are the same way I know what words in my native tongue

I am not sure what point you are getting at here.

> mean.  By itself, the "all" implies that the argument is a collection. 

Yes, agree.

> If it's "fooAll:" where "foo" is a verb, and especially if there exists
> a "foo:" method in parallel, then I stand by claiming that the
> expectation is that the method will iterate over the argument and
> perform a "foo" on all of them.

My expectation is that they will all get foo'ed. Period. Can't see why
it would imply an iteration just because that is the common
implementation. Or in other words - I wouldn't be suprised if there was
an iteration in there, and if someone wanted me to guess about it I
would probably guess that too - but I wouldn't argue that if there
wasn't an iteration in there the implementor somehow broke some
"unspoken contract" of some kind.

But perhaps we are simply misunderstanding each other here. I am still
arguing this because I felt that encapsulation is important and the
argument raised by Andrew (I think) that there was an iteration implied
and therefore that is what it should be - then I disagree.

One perfectly good way of implementing "x removeAll: x" (so that it
works - all other arguments aside) would be to simply empty x. So in
that case no iteration takes place whatsoever.

But I can understand arguments about portability etc so as long as we
add removeAll (no colon) then issuing a signal is fine by me.

> Your data actually agrees with this analysis.  I didn't mean to say that
> the methods were *implemented* to literally use #do:.  In fact, a
> primary reason to have optimized implementations of removeAll: is to get
> rid of the explicit iteration.  Nevertheless, they will examine the
> elements of the argument in some fashion.  It seems a very heavy burden
> to require them to tolerate the argument changing as the method does
> it's work.   As a general rule, experienced Smalltalkers will not expect

Wait a minute - I am not arguing for that. I am simply saying that I
don't agree about "implied iteration".
That was all.

regards, Göran