[ANSI-Smalltalk] Behaviour of #collect:

Ralph Johnson johnson at cs.uiuc.edu
Tue Sep 23 13:04:49 BST 2008


My objection to Richard's proposal that String>>collect: should return
either a string or an array was because  the implementation of
#collect: that he gave was so complicated.  And probably slow, though
I didn't measure it.  But I could see the appeal of having it work
that way.

How about having String>>collect: start by trying to produce a string,
as usual.  However, if the block produces a non-character, storing
that in the string will raise an exception, and it will catch that
collection, copy everything it has produced so far into an array, and
use the array for the result.

This would not be too complex, and would not be much slower when it
produces a string.  Would it be a good idea?

I am still skeptical.  I have never found this to be a problem, and I
use #collect: a lot.  When I store something into a string that isn't
a character, it is almost always that it was supposed to be a
character and I computed it wrong.  I can't ever remember a time when
the problem was really that the string should have been an array,
perhaps because it is an easy problem to fix and so not memorable.  I
think that making String>>collect: silently return an array if the
block returns a non-character is like making every object understand
#do: or #value; something that looks good at the time but turns out to
be a bad idea.   We want the system to tell us when we make a mistake,
and the sooner, the better.

-Ralph



More information about the ANSI-Smalltalk mailing list