[squeak-dev] [ANN] CoroutineReadStream (again)
siguctua at gmail.com
Mon Dec 14 21:28:10 UTC 2009
2009/12/14 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> 2009/12/14 Stephen Pair <stephen at pairhome.net>:
>> On Mon, Dec 14, 2009 at 12:56 PM, Colin Putney <cputney at wiresong.ca> wrote:
>>> On 2009-12-13, at 5:22 PM, Stephen Pair wrote:
>>> > This version fixes a bug in #close that causes the coroutine to not get
>>> > unwound when the stream is closed. Also, it now uses the stream itself as a
>>> > marker instead of a special string (a suggestion from Eliot). I've also
>>> > created unit tests (which is how I caught the problem with close). Below is
>>> > the class comment:
>>> Awesome. I've been meaning to implement this for Filesystem. Thanks!
>> Can you describe how it would be used with Filesystem?
>> - Stephen
> Maybe an encoder/decoder pattern ?
> Example: convert cr-lf pairs to cr only
> [ :outputStream |
> [inputStream do: [ :ea |
> outputStream acceptNextObject: ea.
> ea == Character cr ifTrue: [inputStream peekFor: Character lf]]]
Nope, stream -> stream chaining is a natural thing. Of course you can
use CoroutineReadStream wherever you want, but its purpose is a little
As to me, that CoroutineReadStream is nice wrapping , providing a
transformation from block iterators
to stream. It switching from the 'push' logic (where provider pushing
values to consumer) to 'pull' (where consumer asks provider to give
next value(s), when ready to process next value).
An iteration blocks usually don't decide if they willing to get next
value or when (hence 'push'), and as a consequence its hard to switch
the iterator's logic in the middle of iteration.
While with streams its easy. A patterns like:
(stream next = $x) ifTrue: [
self decodeFooFrom: stream. ].
stream upto: $y.
self decodeBarFrom: stream.
easy to do with streams, but will be awkward for implementing inside
Igor Stasenko AKA sig.
More information about the Squeak-dev