[dojo-contributors] Promises

Kris Zyp kzyp at dojotoolkit.org
Thu Mar 4 10:31:49 EST 2010



On 3/4/2010 2:44 AM, Bill Keese wrote:
> Thanks for working on this 
> (http://bugs.dojotoolkit.org/attachment/ticket/10814/Deferred.js).    I 
> tested it out and it seems to be working, not sure if you have a test 
> file but I wrote a bunch of tests and uploaded them to 
> http://bugs.dojotoolkit.org/attachment/ticket/10814/Deferred.2.js.   No 
> tests about progress or the canceller, you should add some tests for that.
>
> A few minor things:
>     - What's the relation between Promise and Deferred in your code (why 
> are there two classes)?   I thought there would be a dojo.Promise class 
> but there isn't, just a local variable called Promise.
>   

A promise is the entity that you can listen for completion of the
operation, and provides then(), addCallback(), and friends. A Deferred
is entity for resolving the promise, and provides the resolve/callback,
reject/errback. In this implementation the Deferred objects are a type
of promise, so Deferreds have the listener functions as well. A promise
object can't be directly created, because it just represents the
consuming side of an action, and is therefore only available in
conjunction with a Deferred. A plain promise (without the resolution
functions) is available from the "promise" property of a Deferred
object, and is returned by then() calls. These promises meet the OCap
need of being able to pass around a promise without risk of modification
of the resolved value.

>     - the code sort-of violates our consensus to move away from private 
> functions in closures (ex: an app can't modify Deferred.complete() 
> without changing the whole Deferred function)
>   

I thought this was a guideline, not a strict requirement.
Convention-based privates and closure-based privates each have their
appropriate use cases, and in this case closure-based privates are
appropriate for achieving OCap principles.

>
> We talked about performance in the meeting and Eugene/my worries from 
> http://thread.gmane.org/gmane.comp.web.dojo.devel/12358/focus=12377.  I 
> thought about it some more and I'm not too worried,  although there will 
> be many more Deferred's in dojo 2.0 than in dojo 1.x.
>
> One common case where then() will be called thousands of times is with 
> the dojo.data (at least for a server based store).  I'm assuming that 
> although a store will internally fetch batches of rows from the server, 
> the store API will be to get one row at a time, and that iterator 
> function will return a Deferred.
>   

I would hope not. I've not seen this in any of our server-side stores,
QRS and JRS both use a single deferred chain for query results. And the
way we've discussed this would work with the object store alternative to
the dojo data API, would still involve a single deferred chain (not
per-row deferreds), where a forEach is used to iterate, but there is
still a single promise, not a promise for each callback. It is possible
a store implementation could do something like this, but there is
nothing in our APIs that we encourage such behavior.
> There will also probably be some cases where then() is called many times 
> on the same Deferred, but hopefully not enough to be an issue.   For 
> example a FilteringSelect might return a Deferred from attr("value") 
> because it's value is not always immediately available (it requires a 
> lookup in the data store mapping what the user typed, like "california", 
> into a value like "CA".  And FilteringSelect.attr("value") could be 
> called many times by (for example) form level code that keeps querying 
> the value of all the form widgets.  Same thing for widget error state 
> (myFormWidget.attr("state")), error state might not be immediately 
> available so that attr("state") would return as a boolean Deferred.
>   

Right, but this seems much more bounded, and less likely to involve
hundreds of deferreds. Its also worth noting that the old Deferred
implementation created a new array for each callback, which is just as
expensive as object creation, and I have never heard complaints
specifically about Deferred's speed before.


More information about the dojo-contributors mailing list