jburke at dojotoolkit.org
Wed Mar 3 17:47:40 EST 2010
On Wed, Mar 3, 2010 at 2:10 PM, Kris Zyp <kzyp at dojotoolkit.org> wrote:
> I put together a backwards compatible variant of this implementation.
This sounds promising. Ha, see what I did there? OK, that already
sounds lame to me after just saying it.
Anyway, I am keen to see this in a 1.5, even better if it meshes with
the CommonJS Promises. However it seemed like the CommonJS version was
still in flux? Kris, how do view the state of the process/progress
over in CommonJS-land? Any possible implementation divergence between
our code and theirs?
I am also not so keen on a setTimeout for the error case. It means we
need a setTimeout implementation for whatever environment runs the
code, and for debugging, it loses the stack trace.
I appreciate that it is a hard thing to sort out. Some
Deferred/Promise use expect errors to just be eaten but other uses
what to know about errors. The basic problem seems to be not knowing
the error intention at the point of calling the reject/errback.
With traditional Dojo use of Deferreds, it seemed almost reasonable to
say if there was no errback listeners when the error is thrown we can
just throw in that case.
However, with a dojo.when(something, callback, errback) sort of
approach, the errback listener is likely not be be bound until after
the something's Deferred may have erred out? I'm thinking out loud a
bit here, maybe Kris or Eugene have other suggestions on how to look
at the problem.
Making sure these things are easy to debug is a pretty big deal. After
spending some time in Twisted land, and dealing with the current state
of dojo.Deferred error debugging, tracking down errors effectively
would make this sort of deferred/async logic a lot easier to get into.
More information about the dojo-contributors