unlike all other popular c-derivatives, javascript is the only one that's *not* a blocking-code language by design. maybe tc39 should do some outreach to educate the many language-designers and polyglots who only know blocking-code patterns of this simple fact.
as i've said before, adding these foreign, blocking-code design-patterns from java/c#/python/c++ can only get you so far with insignificant, low-level library-code, which is not what javascript is about. javascript is about integrating non-blocking io and workflows, so that browser/webview UX’s don’t block-and-freeze and give the appearance a webapp has crashed. but async/await will save us! …no it will not. the hard-part of integration-level javascript is not writing non-blocking code, but debugging non-blocking code. and debugging non-blocking generator-magic (and promise-magic), is generally more difficult than debugging magic-less recursive-callbacks. there is currently an industry-glut of so-called “senior” javascript-developers, who only know how to write low-level library-code (and bikeshed them to death with let, const, destructuring, etc...), but are clueless on how to integrate whatever-it-is-they-wrote into a shippable web-product. no, they usually need an “intermediate” frontend-developer to do that (who oftentimes didn’t have formal cs-training and wasn't brainwashed with all that blocking-code cr*p that hinders the "senior” developer from carrying out integration-work). -kai > On Mar 23, 2018, at 3:21 PM, Naveen Chawla <[email protected]> wrote: > > I'm still not seeing a compelling case for not allowing `const` / `let` > declarations to be evaluated as expressions. Or I've missed it. > > As was noted, > > `if(x = 5)` is already allowed. > > Is `if(const x = 5)` really that much of a stretch? > > To answer a concern about a function call like `myFunction(const x = 7)`, of > course the scope of `x` would be where it is declared. It can't be anywhere > else (like inside myFunction or something). > > On Thu, 22 Mar 2018 at 22:53 Isiah Meadows <[email protected] > <mailto:[email protected]>> wrote: > Probably true, more so than the `if (var ...)`/etc. (which can't be as > easily desugared). My `else` variant desugars more to something that > is also easily simulated, and it's a less common case: > > ```js > let foo = bar else return baz; > > // Desugared > let _tmp = bar; > if (tmp == null) return baz; > let foo = _tmp; > ``` > > In this case, there's also the question of whether to require a > `return` in all code paths, which probably makes this a bit more > complicated than what would be worth for such a simple language > feature. > ----- > > Isiah Meadows > [email protected] <mailto:[email protected]> > > Looking for web consulting? Or a new website? > Send me an email and we can get started. > www.isiahmeadows.com <http://www.isiahmeadows.com/> > > > On Thu, Mar 22, 2018 at 12:23 PM, Michael Luder-Rosefield > <[email protected] <mailto:[email protected]>> wrote: > > That strikes me as territory the 'do expression' proposal > > https://github.com/tc39/proposal-do-expressions > > <https://github.com/tc39/proposal-do-expressions> is more fitted for: > > > > const x = do { if (c) expr; else { ... } }; > > > > What I'd like for this proposal is something that works consistently and > > obviously for all blocks with a parenthesised element to them. When they're > > formally separated by semi-colons, as in `for (a;b;c)`, each of `a,b,c` acts > > as an expression. Why not allow any of those expressions to be replaced by a > > statement block that acts like a do expression, each of which's scope is > > nested under the previous one and are available to the following block? > > > > That didn't come out very clearly, so let's try with an example: > > > > for ({ > > let x = 1, y = 2; > > console.log("I'll be printed every loop!"); > > }; { > > let s = 'some string'; > > if (y%7 === 0) x === y; > > else x < 1000; > > }; { > > let s = 'some other string'; > > x+=1; > > if (y%3 === 0) y += 2; > > else y += 1; > > }) { > > // whatever code here > > // local scope hierarchy is > > // { > > // x, > > // y, > > // __SCOPE__: { > > // s: 'some string', > > // __SCOPE__: { > > // s: 'some other string' > > // } > > // } > > // } > > } > > > > I'm just using some random logic in the blocks to illustrate the point: all > > the variables declared in the blocks are accessible in the for block, but > > the 'some string' `s` is masked by the 'some other string' `s` in the child > > scope. The termination condition in the second block can vary each loop, as > > can the iteration operation in the last block, and is simply the last value > > in the block as-per do expressions. > > > > On Thu, 22 Mar 2018 at 15:44 Mike Samuel <[email protected] > > <mailto:[email protected]>> wrote: > >> > >> On Thu, Mar 22, 2018 at 3:50 AM, Isiah Meadows <[email protected] > >> <mailto:[email protected]>> > >> wrote: > >>> > >>> > >>> I do have one other related thing I'd like to see: add a `let foo = > >>> expr() else { ... }` variant, with a line terminator restriction > >>> before the `else` so it can't be confused with an `else` within an > >>> `if`. > >> > >> > >> Making it a restricted production would solve the grammatical ambiguity > >> for existing code, but maybe in an errorprone way for future code: > >> > >> if (c) let foo = expr() else { ... } // else attaches to let > >> if (c) let foo = expr(); else { ... } // else attaches to if > >> > >> > >> Would the semantics differ from > >> > >> let foo = expr() || ({} => { ... })() > >> > >> ? > >> > >> > >> > >> > >>> > >>> > >>> ----- > >>> > >>> Isiah Meadows > >>> [email protected] <mailto:[email protected]> > >>> > >>> Looking for web consulting? Or a new website? > >>> Send me an email and we can get started. > >>> www.isiahmeadows.com <http://www.isiahmeadows.com/> > >>> > >>> > >>> On Thu, Mar 22, 2018 at 3:21 AM, Rodrigo <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > Not just let-scopes, but the introduction of `async/await` also > >>> > welcomes the introduction of if-scoped variables. > >>> > > >>> > if (const data = await collection.find({}).toArray(); data.length > > >>> > 10) > >>> > { > >>> > console.log(data); > >>> > } else if (data.length > 0) { > >>> > console.log(data); > >>> > } else { > >>> > console.log(data); > >>> > } > >>> > > >>> > And, as mentioned by @jerry, this can be extended to `switch` and > >>> > `while`. Golang has `switch(;)` initialization too afaik. > >>> > > >>> > switch( const today = new Date(); today.getDay() ) { > >>> > case 0: > >>> > console.log( "Don't work on %s", today.toString() ); > >>> > break; > >>> > } > >>> > > >>> > `while` would be a bit unnecessary, due to the fact that it can be > >>> > replicated with `for( <assign>; <expression>; )`, but could be > >>> > available for consistency with `if` and `switch`. > >>> > > >>> > El mié., 21 mar. 2018 19:47, Mike Samuel <[email protected] > >>> > <mailto:[email protected]>> > >>> > escribió: > >>> >> > >>> >> > >>> >> > >>> >> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton > >>> >> <[email protected] <mailto:[email protected]>> > >>> >> wrote: > >>> >>> > >>> >>> Because block-level scoping is a very good way to avoid certain bugs > >>> >>> and > >>> >>> is easier to reason about. Especially when considering project > >>> >>> successors. > >>> >> > >>> >> > >>> >> +1. function-scoped variables in loop bodies caused tons of bugs > >>> >> before > >>> >> let-scoped variables and were a main motivating case. > >>> >> > >>> >> var i; > >>> >> for (i = 0; i < arr.length; ++i) { > >>> >> f(function () { /* Do something with */ arr[i]; }); > >>> >> } > >>> >> > >>> >> vs > >>> >> > >>> >> for (let i = 0; i < arr.length; ++i) { > >>> >> f(function () { /* Do something with */ arr[i]; }); > >>> >> } > >>> >> > >>> >> Yes, linters got pretty good at finding uses of closed-over variables > >>> >> modified in a loop, but the workarounds were not ideal. > >>> >> > >>> >> var i; > >>> >> for (i = 0; i < arr.length; ++i) { > >>> >> f(function (i) { return function () { /* Do something with */ > >>> >> arr[i]; } > >>> >> }(i)); > >>> >> } > >>> >> > >>> >> Block scoping is just better for code that uses loops, variables, and > >>> >> function expressions. > >>> >> > >>> >> _______________________________________________ > >>> >> es-discuss mailing list > >>> >> [email protected] <mailto:[email protected]> > >>> >> https://mail.mozilla.org/listinfo/es-discuss > >>> >> <https://mail.mozilla.org/listinfo/es-discuss> > >>> > > >>> > > >>> > _______________________________________________ > >>> > es-discuss mailing list > >>> > [email protected] <mailto:[email protected]> > >>> > https://mail.mozilla.org/listinfo/es-discuss > >>> > <https://mail.mozilla.org/listinfo/es-discuss> > >>> > > >> > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] <mailto:[email protected]> > >> https://mail.mozilla.org/listinfo/es-discuss > >> <https://mail.mozilla.org/listinfo/es-discuss> > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
