On 10/21/2011 11:01 AM, David Herman wrote:
[snip]
But there's more to it than just the interface. You fix a particular
scheduling semantics when you put deferred functions into the
language. I'm still learning about the difference between the Deferred
pattern and the Promises pattern, but the former seems much more
stateful than the latter: you enqueue another listener onto an
internal mutable queue.
At least in the Dojo community (and I think Kowal does with Q as well),
we define a Deferred producer-sider constructor for creating promises,
with an API that can resolve() or reject() the generated promise. The
promise is then the consumer-side interface that allows consumer to
register a callback for the fulfillment or rejection of the promise
(with a then() method or a variety of other convenience functions). The
mutable state pattern was used in earlier versions of Dojo, but later we
switched to an API that keeps promises immutable except for legacy
methods, as we have reached consensus that mutable promises are bad.
Thus the terminology difference between mutable state and immutable
state is simply "wrong" vs "right" for us ;).
There are indeed different scheduling semantics to consider. With Dojo
(and I think jQuery as well), we have considered enqueuing callbacks
onto the event queue to unviable because historically the only mechanism
within the browser has been setTimeout (there is no setImmediate or
process.nextTick available) which has a rather large minimum delay that
can easily up add to noticeable and unacceptable introduction of delays
with a chain of a series of promises. Consequently our implementations
do not enqueue any callbacks for future turns, all callbacks are
executed in the same turn as the resolution of the promise, and due to
latency concerns we haven't really felt the freedom to explore other
scheduling semantics. This scheduling semantic has worked fine for us,
but I don't mind an alternate one. It looks like kriskowal/q does
enqueue, using a postMessage hack to enable faster enqueuing on newer
browsers.
On 10/21/2011 10:34 AM, John J Barton wrote:
Can anyone summarize how these proposals relate to Kris Kowal / Kris
Zyp / Mark Miller Q library:
https://github.com/kriskowal/q
The proposal was designed such that it should work smoothly with Kowal's
Q originating promises as well (acting like Q.when). For example, using
the opening example of delay function from the kriskowal/q readme, one
could write:
function(){
return afterOneSecond(yield delay(1000));
}
and it would be effectively the same as (with the possible exception of
scheduling policies):
function(){
return Q.when(delay(1000), afterOneSecond);
}
In my experience, reasoning about the code was much easier with Q than
without Q. (Not something I found in trying generators). I found the
documentation hard to follow since it assumes background I don't have
and the examples were not interesting to me, but once I tried it I was
pleasantly surprised. It does have ergonomic issues, an undefined and
resolved promise work equally well, but I think this may be
inexperience on my part.
Yes, kriskowal/q is an excellent library.
Thanks,
Kris
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
