[dojo-contributors] Promises

Kris Zyp kzyp at dojotoolkit.org
Mon Mar 8 19:25:49 EST 2010


I just did, and it looks like all the dojo.Deferred tests pass on IE,
and the dojox.lang.async tests are passing as well (on FF and IE). I
believe there may still be an outstanding issue with DeferredList
(manifested as an issue in the tree), that I need to fix.
Kris

On 3/8/2010 4:22 PM, Eugene Lazutkin wrote:
> 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
> http://lazutkin.com/
>
>
> 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
_______________________________________________
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




More information about the dojo-contributors mailing list