water at tunes.org
Tue Jun 22 08:01:42 UTC 2004
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:
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
> I strongly dislike Brian Rice's recommendation; there's an assumption
> 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
> 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
Brian T. Rice
LOGOS Research and Development
More information about the Squeak-dev