[dojo-contributors] Promises

Eugene Lazutkin eugene at lazutkin.com
Mon Mar 8 18:22:55 EST 2010

Hash: SHA1

So, did you try to run any existing tests to see if everything works as
expected? Does it work on IE?

Did you try to see if dojox.lang.async still working, or should I look
into that?

Eugene Lazutkin

On 03/08/2010 11:42 AM, Kris Zyp wrote:
> Thanks for pointing these, the fixes should be in the ticket now
> (http://bugs.dojotoolkit.org/ticket/10814).
> 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.
> Kris
> 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
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dojo-contributors mailing list