Addenda:

On Jun 22, 2004, at 1:01 AM, Brian Rice wrote:

> 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 Slate, any Sequence is compatible with other Sequences, of which  
Strings and Repetitions are both kinds. Streams (those with target  
objects) can pass over nearly any collection, not just arrays or  
OrderedCollections. There is a lot more flexibility and abstraction.

Also, nextPutAll: is replaced with a binary selector, to make  
expression composition easy (and so it appears similar to  
concatenation, which makes rewriting such expressions simpler).

>> 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.

Slate's stream libraries are extensive:
Manual entry: http://slate.tunes.org/doc/progman/node19.html
Source code:
http://slate.tunes.org/cgi-bin/viewcvs.cgi/slate/src/stream.slate? 
rev=1.57&content-type=text/vnd.viewcvs-markup
http://slate.tunes.org/cgi-bin/viewcvs.cgi/slate/src/iterator.slate? 
rev=1.43&content-type=text/vnd.viewcvs-markup

They should be more extensive, but many features you would expect to  
find in these modules are elsewhere, and none the poorer for it,  
because of the way Slate works.

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