I am aware that I'm kicking a potentially angry beehive by bringing up this
topic, but I wanted to just have some discussion around if there's any
possibility that JavaScript can, in the near term, have a native mechanism
added to it for better managing of sync vs. async coding patterns, without
I will reveal that what you propose is more or less possible with plain
vanilla ecmascript 3. To modify your syntax proposal, what the syntax would
look like is something like this:
$(document).X(1,2).Y(3,4).Z(foo);
this call returns an object, with a call, and an apply method (possibly a
var task = new Task(function() {
var request = new HttpRequest();
try {
var foo = yield request.send(this, foo.json);
var bar = yield request.send(this, bar.json);
var baz = yield request.send(this, baz.json);
} catch
This reminds me of a proposal by Kris Zyp a couple of months ago
(single frame continuations)
https://mail.mozilla.org/pipermail/es-discuss/2010-March/010865.html
I don't think that discussion lead to a clear outcome, but it's definitely
related, both in terms of goals as well as in
No, that's not the case. That code was not hypothetical: it works in
SpiderMonkey using extensions that have been around for several years. You
might want to take some time to explore generators by following the docs
that Mike linked to, and by playing with SpiderMonkey.
OK, clearly I have
I think given the side effects wanted these are the list of features in
this proposal:
1. code run in this statement does so at the first opportune moment (sync
runs immediately)
2. code in this statement does not start execution until some condition is
true
3. code that encounters and
Lastly, I'd say that function signatures which currently accept a
callback also don't *have* to change. In fact, there may be some value in
allowing both styles (existing callbacks, and my new proposed style) to
co-exist in the same function, giving the calling developer the freedom to
4. Control of execution (that is, the actuall calling of a function) is
linear in the chain in the calling code, rather than being controlled by the
code inside a function.
Another reason I feel it's important to address being able to retain control
of the execution of the chained functions
So why not just add a sandbox, and ... means to catch error
Other than the `import` / `export` thing I mentioned, for the exact reason
why `eval(..)` and `new Function(..)` are not preferred (which roughly do
the same thing)… A feature test that requires the entire
parse/compile/execute cycle
9 matches
Mail list logo
