[dojo-contributors] Promises

Kris Zyp kzyp at dojotoolkit.org
Mon Mar 8 12:42:46 EST 2010

Thanks for pointing these, the fixes should be in the ticket now

Also, I attempted to use dojo.config to get the deferred error handler
(L#81), but I am not sure if I got it right, so feel free to correct that.

I added some more unit tests as well, I think the main thing it needs
now is docs. I'll probably merge some of the olds docs with some of the
explanations of immutable promises.

On 3/6/2010 12:36 PM, Eugene Lazutkin wrote:
> Finally I looked at the code and I like it. I liked that the
> setTimeout() hack is gone (but can be recreated externally if needed). I
> liked that then() doesn't always create a new object to return (e.g.,
> while working in the compatibility mode). In general I found the code to
> be compact and easy to understand.
> Obviously bugs should be fixed first before attempting to replace Bob
> Ippolito's Deferred. Like "head" being global (lines #105 and #108) ---
> right now all callbacks are being appended to the very last Deferred.
> Another obvious bug is in line #87: you call "promise" as a function yet
> it can be an object called "MUTATOR" (see lines #26 and #92), which
> appears to by un-callable.  Of course, correct me if I am wrong: I
> didn't run the code, just looked at it once, and I might miss something
> essential.
> Another thing I would do is to move dojo.when() definition outside of
> the closure --- it doesn't rely on any hidden variables and defines one
> global variable, so why placing it here? Obviously this is not a bug but
> my personal preference --- I spent time trying to figure out why it was
> there, and what hidden stuff it used. It appears to be "clean" but will
> link to the closure (at least on IE).
> And the old functionality should be duplicated (I know you spent time
> doing it, just double-check it) --- our codebase working is a good
> criteria, but we have users with their code too. Personally I would be
> thrilled to see that dojox.lang.async works as it did before.
> Eugene Lazutkin
> http://lazutkin.com/
> PS: With these bugs you got some tests and code running. It tells us
> something: it appears that the most common pattern is to create one
> Deferred, and work with it exclusively adding callback(s), then work
> with the other one. It confirms one thing I knew before: adding
> callbacks in different places at different times are rarely used.
> One corollary is: the chaining of callbacks is overrated. That's why I
> am not keen on chaining using a newly returned separate object (like
> then() did in your original implementation) --- an extra code for
> nothing, an extra object creation which in most cases will be simply
> discarded --- more load on CPU and memory for basically nothing.
> On 03/05/2010 07:57 AM, Kris Zyp wrote:
> > After thinking about this more, I am probably being a little too
> > pedantic in pursuing semantic purity. I think you are right Eugene,
> > simply doing a console.error for every error as a default action that
> > can overriden is fine behavior for the majority of applications, gives
> > good error visibilty, and those that need to suppress the error logging
> > can, and removing the logic (the setTimeout and error tracing) to detect
> > uncaught errors actually saves a few dozen bytes. I uploaded new version
> > to the ticket, do you want check to see if this is adequate:
> > http://bugs.dojotoolkit.org/attachment/ticket/10814/Deferred.js#L80
> > Does this sound good to everyone?
> > Thanks,
> > Kris
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org

More information about the dojo-contributors mailing list