Hi Kris,
Your proposal has a lot of similarities to
http://wiki.ecmascript.org/doku.php?id=strawman:deferred_functions
which was proposed this past spring.
I'm not sure I follow what's top-down vs bottom-up about the two different
approaches. Let me suggest some terminology that has emerged in the proposal
process: I'll use "generators" to mean any single-frame, one-shot continuation
feature that's independent of the host event queue, and "deferred functions" to
mean any single-frame, one-shot continuation feature that is tied to the host
event queue by means of being automatically scheduled.
> Generators directly solve a problem that is much less significant in normal
> JS coding. While it is exciting that generators coupled with libraries give
> us a much better tool for asynchronous use cases (the above can be coded with
> libraryFunction(function*(){...}), my concern is that the majority use case
> is the one that requires libraries rather than the minority case, and does
> not promote interoperability.
It's true that generators require libraries in order to use them for writing
asynchronous code in direct style. And I agree with you and Alex and Arv that
there is a cost to not standardizing on those libraries. There are different
frameworks with similar but incompatible idioms for Deferred objects, Promises,
and the like, and they could be standardized.
> A couple years later, I believe the landscape has dramatically changed, and
> we indeed do have significant convergence on a promise API with the
> "thenable" interface. From Dojo, to jQuery, to several server side libraries,
> and apparently even Windows 8's JS APIs (from what I understand) all share an
> intersection of APIs that include a then() method as a method to define a
> promise and register a callback for when a promise is fulfilled (or fails).
> This is an unusual level of convergence for a JS community that is so
> diverse. I believe this gives evidence of well substantiated and tested
> interface that can be used for top-controlled single-frame continuations that
> can easily be specified, understood and used by developers.
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. I'm not sure how much state can be
avoided with listeners (at the end of the day, callbacks have to be invoked in
some particular order), but that concerned me when I saw the deferred functions
proposal. I can't prove to you that that scheduling policy isn't the right one,
but I'm not ready to say it is.
So I'm not sure all scheduling policies are created equal. And with generators,
at least people have the freedom to try out different ones. I'm currently
trying one with task.js, and I hope others will try to come up with their own.
(There's also the added benefit that by writing the scheduler in JS, you can
instrument and build cool tools like record-and-reply debugging.)
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
