language. I don't understand how that can be true, since it is
possible to dynamically add bindings to the global environment by creating
new global properties (during code evaluation). Isn't this a static scope
violation, too?
-- Šime Vidas
___
es-discuss
at compilation if “ooops”
belong the the global scope of from the function’s scope (we can only find
that out at runtime).
*From:* Šime Vidas sime.vi...@gmail.com
*Sent:* Wednesday, October 03, 2012 6:41 PM
*To:* es-discuss@mozilla.org
*Subject:* Is ES5 Strict a fully statically scoped language
On Thu, Oct 4, 2012 at 12:31 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Oct 3, 2012 at 3:16 PM, Šime Vidas sime.vi...@gmail.com wrote:
On Wed, Oct 3, 2012 at 7:05 PM, François REMY
fremycompany_...@yahoo.frwrote:
I think that what he meant is that we know for sure in which
With block statements + let/const, IIFEs are no longer needed to emulate
block-scoped variables. That got me thinking, are there other uses of
IIFEs, or are they no longer needed?
I’ve checked my code and found instances of this pattern:
var foo = (function () {
var a, b, c; // helper
Say I have an array over which I need to iterate multiple times, but I need
the index value only some of the time. Is it possible to create a custom
iterator which auto-detects when I need the index and feeds me entries()
instead of values() in those cases? For example:
array[Symbol.iterator] =
Daniel Brain from PayPal has written a post about async/await:
https://medium.com/@bluepnume/even-with-async-await-you-probably-still-need-promises-9b259854c161
It revolves around writing an async function which would execute three
tasks in parallel like so:
|- dough ->
|
To clarify, the idea is to declare and kick off all the concurrent tasks
upfront (using local variables and the ‘lazy await’ keyword), and then just
continue writing the rest of the code ‘as if all the promises are
resolved’. The async function automagically pauses whenever needed, so it’s
no
>
> Domenic's version using current `async`/`await` syntax is nice and clear
> (one might tweak the variable names a bit to differentiate promises from
> resolved values, but...).
>
This is the issue I have with this approach. The author is forced to create
two sets of variables (for promises and
Yes, I think you nailed it. I didn’t make the connection before. Instead of
awaiting upfront, forcing the async operations to run in sequence, the
awaits are ‘moved’ to the variables themselves, allowing the async ops to
run in parallel (as much as possible), and once one such variable is used
(in
9 matches
Mail list logo
