Promises, callbacks, Continuables and more - nodejs

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Promises, callbacks, Continuables and more
Received-SPF: pass (google.com: best guess record for domain of inim...@inimino.org designates 67.207.138.202 as permitted sender) client-ip=67.207.138.202;
Message-ID: <4B65A102.6050307@inimino.org>
Date: Sun, 31 Jan 2010 08:25:54 -0700
From: inimino <inim...@inimino.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20100108 Icedove/3.0
MIME-Version: 1.0
To: nodejs@googlegroups.com
Subject: Re: [nodejs] Promises, callbacks, Continuables and more
References: <4B64AD2E.30709@inimino.org> <fc3b3f241001301633u4fa1abfbqe0042fb6e681af07@mail.gmail.com>
In-Reply-To: <fc3b3f241001301633u4fa1abfbqe0042fb6e681af07@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Jonas,

On 2010-01-30 17:33, Jonas Pfenniger wrote:
> Hi inimino,
> 
> The FileIO proposal was interesting to read. I had a good fun wrapping
> my head around the closures.
> 
> Here are some raw reflections I had while studying the code:

Thanks.

> * addCallback, errback is more expressive and thus probably more
> abordable to newbies ?

Yes, probably.  Isaacs mentioned this on IRC as well.  I'm not 
sure if the gained clarity warrants the verbosity.  Personally 
in my experience with Promises so far I have found them just a 
little beyond my tolerance for verbosity, so I'm leaning towards 
brevity, even at the cost an extra minute or two of explanation 
for newbies.  (Async APIs tend to need explanation anyway.)

> Given this code:
> 
> node> s=file.streamLines('11.txt','ascii')
> node> s(function(message_type){puts(message_type)})
> node> s('next')
> 
> a) Imagine s('next') throws an exception randomly. Since s('next') is
> sometimes synchronous, sometimes not, will I have two different
> exception paths ?

Yes.

> b) Why not use a second variable for the stepper ? streamLines ::
> Path, Encoding -> Callback -> Stepper (not sure about the Haskell
> notation). Whith each callback spawning a new reading stepper.
> node> s=file.streamLines('11.txt','ascii')
> node> var s2 = s(function(message_type){puts(message_type)})
> node> s2('next');

I like this API, but it would require buffering the stream 
contents since the steppers are independent and can read the 
stream at different rates.

As for whether a stream should return a separate stepper, or 
the caller should continue to call the stream itself with 
'next' messages... I wasn't quite sure which was the best.

I went with what I did mainly so that things like 

node> s(function(){ ... s('next') ...})

don't have to be written using an extra assignment:

node> var s2=s(function(){ ... s2('next') ...})

> c) By the way, why not let the stepper be an object. s2->next() and s2->close()

I wanted to build an API with functions in place of objects. 
After all, if you have closures, you don't really /need/ 
anything else... fileIO is partly an experiment in building 
APIs on that principle, and then seeing how nice we can make 
them.

> * stat, open and read implementations don't have return values ?

Right, the low-level (undocumented) ones in process.fs that I'm 
using don't have (meaningful) return values, they just call their 
callback with a value when they have one.

Thanks for your thoughts!  It's really helpful to get other's 
responses to these ideas.

-- 
http://inimino.org/~inimino/blog/
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
