Just posted a git with an implementation: https://gist.github.com/2519472
On Saturday, April 28, 2012 4:03:37 PM UTC+2, Bruno Jouhier wrote:
>
> Hi Jorge,
>
> Yes, this is just the way things are in node.
>
> I would probably do it slightly differently, as you suggest, with an API
> that lets you read the prime numbers one by one:
>
> var nextPrime = primeGenerator.create();
> nextPrime(cb);
>
> State encapsulated in a closure rather than an object. I like that.
>
> Bruno
>
> On Saturday, April 28, 2012 12:04:28 PM UTC+2, Jorge 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
