Re: Would it be possible to add “await on first use” to the language?
On 24 February 2017 at 16:19:03, Šime Vidas (sime.vi...@gmail.com) wrote:
> To clarify, the idea is to declare and kick off all the concurrent tasks
> upfront
Well, that's what promises *already* do, even without using the
`async` and `await` keywords. You kick off all concurrent tasks
up-front - it's only tasks that depend on a previous task's result
that need wait around for that task to finish. Without `async`
functions, you'd probably do something like this:
function makePizza(sauceType = 'red') {
const dough = makeDough(), sauce = makeSauce(sauceType);
const cheese = sauce.then(s => grateCheese(s.determineCheese()));
return Promise.all([dough, sauce, cheese]).then(function([dough,
sauce, cheese]) {
dough.add(sauce);
dough.add(cheese);
return dough;
}
}
With `async` functions, you can avoid all those lambdas and the code's
a little bit cleaner - either way, you don't need new JS magic to do
things concurrently!
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal: anaphoric if and while syntax
In current ECMAScript, it is legal to place a variable declaration inside the
initialiser of a `for` loop, as well as to declare the variable used by a
`for...in` or `for...of` loop within the declaring expression:
for (let i = 0; i < 5; ++i) console.log(i);
for (let item of collection) process(item);
When this syntax is used with `let` or `const`, the resulting variable is
scoped to the loop and is not visible to the rest of the surrounding block.
I propose that this syntax be extended, making it legal to place a variable
declaration within the condition of an `if` or `while` statement. Any truthy
value will cause the `if` block to run or `while` loop to repeat, as usual -
the advantage is that the particular truthy value is bound to a variable and
can be used inside the conditional block. For example, here is the situation
that prompted my writing this proposal:
if (const oldValue = _.get(object, 'some.long.path')) {
object.some.long.path = transform(oldValue);
}
As with the existing behaviour of declarations inside `for`, variables declared
using `let` or `const` would be scoped to the individual `if` or `while`
statement, rather than the containing block. In other words, the above syntax
would be equivalent to the following currently-valid form I ended up writing:
{
const oldValue = _.get(object, 'some.long.path');
if (oldValue) object.some.long.path = transform(oldValue);
}
Another use case which C aficianados might recognise:
while (const c = getchar()) {
process(c);
}
This syntax is already legal in C++, although not in C - in general this
support is known as "anaphoric if", as it allows the body of the statement to
refer back to the condition value. It's especially helpful in languages with
truthiness, which ECMAScript has, as it allows access to the *specific* truthy
value without further finagling.
Thoughts?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: add an option to omit prototype of objects created by JSON.parse()
From: Olivier Lalonde (mailto:olalo...@gmail.com)
Date: 30 September 2016 at 07:21:10
> Given that JSON.parse doesn't necessarily return an object, would the
> noPrototype option would be ignored on e.g. `JSON.parse('"some string"')` or
> `JSON.parse('true')`?
The noPrototype option should set the behaviour whenever the parser
encounters a JSON object (i.e., key-value pairs wrapped in curly
braces). If the JSON text to be parsed does not contain any objects,
then the option will have no effect. 'true', 'some string', and
'[1,2,3,"four"]' are examples of JSON texts which would not be
affected by the noPrototype option. (Note that although an array is a
*JavaScript* object, it's not a *JSON* object.)
Conversely, if the JSON text to be parsed contains multiple objects -
for instance, `JSON.parse('[{"first": 1}, {"second": 2}, {"third":
3}]', {noPrototype: true})` - then *all* of those objects should be
constructed with a null prototype.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: add an option to omit prototype of objects created by JSON.parse()
From: 段垚 (mailto:duan...@ustc.edu)
Date: 28 September 2016 at 16:36:52
> [I]mplementors warn that mutating prototype causes "performance
> hazards".
You don't actually need to mutate any prototypes to get prototypeless
objects out of `JSON.parse` - the reviver function is allowed to
return a new object instead, so you can create a fresh one with the
correct prototype. For example:
```js
JSON.parse(string, function(k, v) {
if (v && typeof v === 'object' && !Array.isArray(v)) {
return Object.assign(Object.create(null), v);
}
return v;
});
```
> How about adding an option to omit prototype of objects created by
> JSON.parse()?
>
> JSON.parse(str, { noPrototype: true });
While you can achieve the appropriate result already without extra
language support, I think this particular situation is common enough
that such an option might be a good idea.
How would you expect this new parameter to interact with the existing
second parameter to `JSON.parse`, the reviver function? I'd suggest
that the cleanest way to add the options would be for the second
parameter to be either an object or function, like this:
```js
JSON.parse(str, someFunc);
// equivalent to
JSON.parse(str, {reviver: someFunc});
```
Another approach would be to use two separate optional parameters,
i.e., `JSON.parse(text[, reviver][, options])`, but generally that
style is very messy.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: anaphoric if and while syntax
"Bergi" wrote:
> What about `else` blocks, would the variables be available in them as well?
No. If the `else` block executes, then the variable's value would be
falsy and therefore presumably not useful for further processing. Of
course, there are multiple falsy values in ES, but knowing which
specific falsy value a condition produced is far less useful than
knowing which specific truthy value a condition produced.
If you've got a use case for the variable's scope extending into the
`else` block, though, feel free to change this. ;)
"Alan Johnson" wrote:
> What about `else if`?
As with a standalone `else`, the `else if` branches are only reached
if the value from the `if` branch was falsy and therefore presumably
not useful. So, again, the variable from the original `if` condition
need not be available.
It should however be possible to declare *another* variable in an
`else if`'s condition, for consistency. Like this:
```js
if (const x = expr()) {
// use x
} else if (const x = expr2()) {
// use x in a different way
} else {
// couldn't get either kind of x :(
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: anaphoric if and while syntax
On 14 September 2016 at 17:58:24, Viktor Kronvall
(viktor.kronv...@gmail.com(mailto:viktor.kronv...@gmail.com)) wrote:
> Does this really need new semantic interpretation of the syntax? Using the
> `Array.prototype` methods `.forEach` and `.map` already mitigates this
> problem as far as I can tell by having a different bound variable (argument
> in this case) for each call.
>
> I agree that the behavior may be non-intuitive if you have a background
> coming from Java or C++ but the implications would be quite far-reaching and
> the backward compatibility with previous versions would be difficult to
> handle. Wouldn't this require a new 'use strict'-like mode?
No, adding anaphoric if as I have described it will require neither
new semantic interpretation of the syntax nor a new strictness
directive. Currently, it is a syntax error to write a variable
declaration within an `if` or `while` condition, so there is no valid
code which contains the proposed syntax.
Also note that under this proposal, declarations made using the `var`
keyword would still be hoisted to function scope, *not* scoped to the
body associated with the condition - i.e., there would be no semantic
difference whatsoever between the following two snippets:
if (var stuff = some.cool(expression)) doThings(stuff);
// equivalent to
var stuff;
if (stuff = some.cool(expression)) doThings(stuff);
Only declarations made with the newer `let` and `const` keywords,
which are never hoisted to function scope anyway, would be narrowly
scoped to the condition and its body.
if (let stuff = expr) doThings(stuff);
// equivalent to
{
let stuff = expr;
if (stuff) doThings(stuff);
}
(An aside: as the last example demonstrates, the `if` or `while`
statement body should not need braces to isolate the scope in this
way. This is consistent with the current behaviour for declarations in
loops.)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Proposal: anaphoric if and while syntax
In current ECMAScript, it is legal to place a variable declaration inside the
initialiser of a `for` loop, as well as to declare the variable used by a
`for...in` or `for...of` loop within the declaring expression:
for (let i = 0; i < 5; ++i) console.log(i);
for (let item of collection) process(item);
When this syntax is used with `let` or `const`, the resulting variable is
scoped to the loop and is not visible to the rest of the surrounding block.
I propose that this syntax be extended, making it legal to place a variable
declaration within the condition of an `if` or `while` statement. Any truthy
value will cause the `if` block to run or `while` loop to repeat, as usual -
the advantage is that the particular truthy value is bound to a variable and
can be used inside the conditional block. For example, here is the situation
that prompted my writing this proposal:
if (const oldValue = _.get(object, 'some.long.path')) {
object.some.long.path = transform(oldValue);
}
As with the existing behaviour of declarations inside `for`, variables declared
using `let` or `const` would be scoped to the individual `if` or `while`
statement, rather than the containing block. In other words, the above syntax
would be equivalent to the following currently-valid form I ended up writing:
{
const oldValue = _.get(object, 'some.long.path');
if (oldValue) object.some.long.path = transform(oldValue);
}
Another use case which C aficianados might recognise:
while (const c = getchar()) {
process(c);
}
This syntax is already legal in C++, although not in C - in general this
support is known as "anaphoric if", as it allows the body of the statement to
refer back to the condition value. It's especially helpful in languages with
truthiness, which ECMAScript has, as it allows access to the *specific* truthy
value without further finagling.
Thoughts?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
