On 10/19/2011 12:29 PM, Dean Landolt wrote:
This is a really great idea, Kris! A few comments inline...
[snip]
If the value is not an object with a "then" property that is a
function, the operand value is the immediate result of the
evaluation of the "yield" expression and execution is not suspended.
Here is a simple example of usage:
"use strict"
function delay(ms){
// a function that will yield for the given milliseconds
yield {
then: function(resume){
setTimeout(resume, ms);
}
}
}
IIUC you're proposing language-level support for promises, right?
There's no getting around it -- you're spec'ing an interface for the
unary yield operator to interact with. So why not go all out and have
the language stratify `then` for you with private names?
That's fine with me.
[snip]
Obviously one could choose a different keyword to use. I'd imagine
"await" is one alternative. The drawback of "yield" is that it
does behave differently than a yield in a generator. However,
generators behave quite differently anyway, and top-controlled
"yield" shares a very important commonality. Using one keyword
means there is only a single operator that can result in a
suspension of execution within a function body, making easier to
spot such occurrences and look for possible points where certain
variants should not be anticipated. Of course it is also nice to
avoid proliferation of keywords and introducing new previously
unreserved keywords.
Any thoughts on how this should interplay with generators? One
side-effect of overloading yield is that it becomes impossible to wait
for a promise inside a generator -- is this a feature or a bug?
I think it is a feature, as I don't believe they both forms can be used
very coherently together in the same function. Consider a separate
"await" operator inside a generator. If you execute this operator with
an unresolved promise, the function is supposed to return (a promise),
but in a generator when a return is encountered it throws a
StopIteration. It hardly seems useful to have an (await somePromise)
immediately halting the generator. If you want to use promises within a
generator, I believe the correct usage would be to propagate the promise
out to the generator controller and then yield from there:
function* slowGenerator(){
while(true){
yield delay(50);
}
}
let seq = slowGenerator();
yield seq.next();
yield seq.next();
There are also have been suggestions about potentially have
language support for queuing different operations on to promises
(gets, puts, and posts). I don't think proposal precludes such
possibilities (it only precludes the possibility of opaque
promises that have no interface, but the majority of devs I have
talked to are pretty opposed to that idea, so that doesn't seem
like likely possibility).
I assume that if a function that yields, when called with a yield
prefix, will return a promise -- is this correct?
Yes.
What if there exists a yield in the function but the function returns
without hitting a yield in the codepath? No promise then?
No promise will be returned.
I believe it is critical that we may maintain a principle of locality
such that:
(function(){
if(false){
<valid statement>
}
else return true;
})();
will always return true, regardless of the operators placed within the
if statement's body.
Thanks,
Kris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
