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 <[email protected]> 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 [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 -- 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 [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
