I've stirred the master library design debater Richard. It's time to 
spar a bit, I suppose! :)

On Jun 21, 2004, at 11:30 PM, Richard A. O'Keefe wrote:

> Brian Rice <water at tunes.org> wrote:
> 	I fully agree, but that's not a tight enough idiom.
> 	How about repeatedTimes:, one method for characters to make
> 	strings, one for objects to make arrays?
> 	
> The obvious question is, "just how common is this operation, anyway?"
> The only time I've ever wanted $c repeatedTimes: n, $c has been
> Character space, and what I've _really_ wanted has been aStream space: 
> n.

I must say that I find this suggestion, to presume that space: exists 
on streams and is somehow more natural, to be a horrible idea, whose 
only factor in its favor is legacy presence from Smalltalk-80. Perhaps 
Squeak is interested in this for its own sake, but I see no reason to 
continue in this path. #space: is nondescript, presumes that streams 
have knowledge of characters, and presumes that they care about 
printing of any kind. While removing space: from Squeak would take a 
bit of work, encouraging continued reliance on it as though its design 
were truly justified instead of haphazard, is intellectually 
irresponsible.

> I strongly dislike Brian Rice's recommendation; there's an assumption 
> here
> that no-one ever wants an Array of Characters, or any other kind of
> indexed collection than Array or String.

What Slate does for timesRepeated: is totally element-type-compatible 
and abstract, creating a Repetition sequence object, with slots for 
element and size. But then in my eyes the only reason this use-case is 
rare in Smalltalk is because it isn't natural with the given idioms. I 
modified my suggestion since there'd be an uproar about a new class 
just for this apparently distasteful idiom.

> In contrast, #repeatedTimes: strongly suggests #timesRepeat: to me, so
> if I see
>     x repeatedTimes: n
> I am *definitely* going to misread this for the next couple of years as
>     n timesRepeat: x
>
> But above all, why do we need a "tight idiom" for an operation so rare?

I'm of the opinion that if there's /any/ kind of idiom, it should be 
refactored into something concise and natural, even if only for the 
sake of seeing whether the idiom is common, can be common, or just to 
reify it for your code-aware environment (senders-browsing). But then 
"I" am not the Squeak "we" in any sense of such a metaphor.

> Maybe it's used a lot in Python, but the Smalltalk way to build up 
> large
> strings is via Streams.

It's too bad then that stream operations in Smalltalk are so clumsy and 
relatively restricted. :-)

I've written the stream libraries in Slate (and debugged and documented 
them like crazy), and I'm totally unsatisfied looking at Smalltalk's 
idioms by comparison. Mine need improvement as well, but I'm at the 
point where I couldn't even imagine performing the next steps 
reasonably in Smalltalk-80, or porting any further Smalltalk (or Flow, 
those being done) stream idioms to Slate, because the remaining ones 
are horrible.

--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/