I agree with you on the hole of readable.push(''). I think it would be better
to have a separate API for these special cases, e.g. a readable.end() to
indicate the stream has ended, and readable.empty() to indicate the same thing
as readable.push('').
With respect to the return value. Yes, theoretically some user may want to
return the value 'undefined' without indicating the end of a stream. But in
practice I have never meet such a case. However, I've meet numerous cases where
the value 'null' is an actual return value, other than indicating the end of a
stream. I agree use something like readable.NULL (or readable.EOF) would be a
solution. But seems gross, and IMO, an overkill.
-Chaoran
On Oct 23, 2013, at 3:39 AM, Benjamin Goering <[email protected]> wrote:
> I agree with both suggestions.
>
> Another hole is the non-objectMode special behavior of readable.push('');
> http://nodejs.org/docs/latest/api/stream.html#stream_stream_push
> When called by a Readable implementation, it is supposed to signal that the
> stream is done getting data from its upstream source, but there was no data
> to fetch. The Readable internals then ensure that another _read() loop is
> called (including checking first if the stream has been paused).
>
> When in objectMode, though, this is ambiguous. .push('') Could mean that the
> implementation would like to push out the empty string, since that's a valid
> object.
>
> I actually need to change this this week (break the spec?) in my
> browser-based implementation of objectMode streams3.
> https://github.com/Livefyre/stream
>
> Currently, .push(), ie pushing undefined, is treated like .push(null), which
> signals EOF and ends the Readable. Instead, I'm going to make .push() be the
> equivalent of .push('') in non-objectMde streams.
>
> This would actually be bad for your case. Just like you sometimes expect
> .read() to return null, theoretically some user may want to .push() the value
> 'undefined'. I'm kind of fine making that sacrifice, but curious if you or
> anyone has a better idea. It could be .push(readable.NULL) or something ( :/
> ). Similarly, if you needed to be able to .read() out the value 'null',
> .read() could return something like readable.NULL. But these seem gross..
>
> On Saturday, October 19, 2013 8:18:28 PM UTC-7, Chaoran Yang wrote:
> Hi all,
>
> I'm trying to implement a stream in object mode. It's a very complex stream
> that allows user read and write database records. But for this discussion,
> you can just imagine it as a duplex stream that reads and writes database
> records in a table.
>
> [Question] I've read the API doc on streams. It's a bit unclear about the
> usage of highWaterMark in object mode. Does it limit the number of objects
> that it internally buffered? If not, how do I control the memory usage of the
> internal buffer?
>
> [Suggestion] The API doc said "a readable stream in object mode will always
> return a single item from a call to readable.read(size), regardless of what
> the size argument is", which feels very unintuitive for me. I think it should
> be more intuitive if readable.read(size) returns "size" items.
>
> [Suggestion] Currently, The special value null still retains its special
> value for object mode streams. That is, for object mode readable streams,
> null as a return value from stream.read() indicates that there is no more
> data, and stream.push(null) will signal the end of stream data (EOF).
> However, in the stream I want to implement, a null object is exactly what I
> want to return to the consumer, and it should not indicate that there is no
> more data. Wouldn't it be more appropriate to use "undefined" as the special
> value to indicate the end of stream data?
>
> Thanks,
> Chaoran Yang
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to a topic in the Google
> Groups "nodejs" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/nodejs/hhtuFJs0_9Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
