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