As i see it: We have a prime number generator that constantly *emits*
prime numbers. This is a *stream* of prime numbers. Thus: Use
stream.Stream.
IMHO implementing this as a stream it is not over-engineered. For me
it is the optimum way as streams provides a standard method for
everything emitting data. It makes it very easy to hook into that
stream of data and do whatever needs to be done with that prime
numbers. I do not have to read lots of API documentation. All i need
to know: It is a standard node stream of data.
BTW: I'm writing this as i recently added 'lazy' to my toolbelt of
indispensable node modules.
On Sat, Apr 28, 2012 at 12:04 PM, Jorge <jo...@jorgechamorro.com> wrote:
> Hi Bruno,
>
> On Apr 28, 2012, at 11:14 AM, Bruno Jouhier wrote:
>
>> Neither!
>>
>> I think that question should be callbacks vs. events vs. streams:
>> • Callback: called only once, when the function is done, to return
>> result (optional) or error.
>> • Event: called repeatedly by the function to notify its listeners.
>> Can be used to send intermediate results as they come.
>> • Stream: higher level concept based on events, with standardized
>> event types (data, end, error, drain) and standardized API (pause, resume,
>> write, ..).
>> So, assuming prime computation is asynchronous:
>>
>> • If the function computes the N first primes and returns them all at
>> once, it should use a callback.
>> • If the function returns the primes one by one, it should use events.
>> It may also use a stream but that seems a bit over-engineered.
>
>
> Good, yes, that's the way it is in node, but it does not explain *why* it is
> so.
>
> .readFile() could as well deliver the chunks to the cb as they're read from
> disk, and to use it you'd need to write just one line:
>
> fs.readFile(path, cb);
>
> While to do the same with an evented interface there's a lot of boilerplate
> to write, and an extra object to create:
>
> reader= new fileReaderConstructor(path);
> reader.on('data', cb);
> reader.on('end', endCB);
> reader.on('error', errorCB);
>
> It seems to me that the former is more functional and makes good use of
> closures (*), while the latter is the approach a classic OOP programmer would
> tend to write instead.
>
> (*)In JavaScript we don't need to create objects to save state.
> --
> Jorge.
>
> --
> 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 nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
--
Oliver Leics @ G+
https://plus.google.com/112912441146721682527
--
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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
