On 3/23/14 at 11:24 AM, bren...@mozilla.org (Brendan Eich) wrote:
Marcus Stade wrote:
This is assuming that the `current` or `prev` property is
indeed implemented by the engine and not user land, as that
indeed both carries implementation cost and the risk out
running out of sync. Is there an
On Mar 23, 2014, at 9:59 AM, Marcus Stade wrote:
> Does this mean that the body of a generator function is strict mode, or just
> that yield is reserved?
No, but within generator functions 'yield' is always interpreted as the yield
operator.
Allen
___
On Sun, Mar 23, 2014 at 7:37 PM, David Bruant wrote:
> Any old object. It's a structural or "duck-typed" protocol.
I see, this was the bit of insight I was missing. Thanks!
-- Marcus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.moz
Le 23/03/2014 19:24, Brendan Eich a écrit :
Marcus Stade wrote:
This is assuming that the `current` or `prev` property is indeed
implemented by the engine and not user land, as that indeed both
carries implementation cost and the risk out running out of sync. Is
there any way other than genera
Marcus Stade wrote:
This is assuming that the `current` or `prev` property is indeed
implemented by the engine and not user land, as that indeed both
carries implementation cost and the risk out running out of sync. Is
there any way other than generator functions to implement iterators?
Are an
Could the iterator protocol be extended to also have a `current` or `prev`
property, which contains the result of the previous call to `next`? If
`next` has never been called, presumably this property would return
`undefined`.
I've searched the archives for this question, and the only semi-satisfy
Does this mean that the body of a generator function is strict mode, or
just that yield is reserved?
-- Marcus
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
7 matches
Mail list logo
