[dojo-contributors] Promises

Eugene Lazutkin eugene at lazutkin.com
Sat Mar 6 14:36:34 EST 2010

Hash: SHA1

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

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

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
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dojo-contributors mailing list