Re: Optional chaining syntax but with the "mice" operator ?

[Tab Atkins Jr.]

On Fri, Sep 6, 2019 at 8:04 AM Andrea Giammarchi
 wrote:
> Indeed I'm not super convinced myself about the "branching issue" 'cause 
> `const result = this?.is?.branching?.already` and all I am proposing is to 
> hint the syntax where to stop in case something else fails down the line, as 
> in `const result = this.?.is is not reached, there is a certain point to keep going (which is, example, 
> checking that `result !== this`)

Important distinction there is that ?. only "branches" between the
intended type and undefined, not between two arbitrary types. The
cognitive load between those two is significantly different.

In particular, you can't *do* anything with undefined, so
`foo?.bar.baz` has pretty unambiguous semantics - you don't think you
might be accessing the .baz property of undefined, because that
clearly doesn't exist.

That's not the case with mouse, where it's not clear, at least to me,
whether `foohttps://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Andrea Giammarchi]

It's 

On Fri, Sep 6, 2019, 20:14 Jordan Harband  wrote:

> Syntactically marking, in a chain, what you'd like the final value of the
> chain to be, seems interesting - forcing optionality into it seems
> unnecessary, though, if such a syntactic marker could be attached to all
> forms of property access.
>
> Something like: `a.b>.c.d` or `a?.b>?.c?.d` or `a>[b][c][d]`.
>
> (Obviously, the `>` won't work with bracket, and any syntax for normal
> properties that only applies to dot and not also bracket would somewhat be
> a nonstarter; but the specific syntax can be bikeshedded separately)
>
> On Fri, Sep 6, 2019 at 8:04 AM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> Indeed I'm not super convinced myself about the "branching issue" 'cause
>> `const result = this?.is?.branching?.already` and all I am proposing is to
>> hint the syntax where to stop in case something else fails down the line,
>> as in `const result = this.?.is> part is not reached, there is a certain point to keep going (which is,
>> example, checking that `result !== this`)
>>
>> On Fri, Sep 6, 2019 at 4:17 PM Naveen Chawla 
>> wrote:
>>
>>> Typically, "dot" expressions navigate through values of different types,
>>> making "type branching" the inevitable next step in those cases (unless you
>>> introduce a common method for further processing for each of those types).
>>> So I'm not sure how ultimately that would be avoided.
>>>
>>> On Fri, 6 Sep 2019 at 14:15, Claude Pache 
>>> wrote:
>>>


 Le 6 sept. 2019 à 14:35, Felipe Nascimento de Moura <
 felipenmo...@gmail.com> a écrit :

 Doesn't that bring risks to breaking the web?

 You seen, many, MANY servers running php have the "shot-tags" feature
 enabled, in which pages with  will be interpreted.
 In this case, any html page with embedded scripts using this operator,
 or event .js files when the server is configured to also run php in them,
 will break.

 Or am I missing something here?

 [ ]s


 Any future PHP file that incorporate that syntax will almost surely
 refuse to compile on servers that has short-tags enabled, making the
 problem evident before it produces something useful on the web. This may be
 an issue, but this is not what “breaking the web” is intended to mean.
 Existing, untouched content will not break. Carelessly updated content
 might break, but that’s not fundamentally different from any other careless
 update.

 (If anything else, it may convince people that having different
 configuration settings w.r.t. short-tags in development environment and in
 production environment, is a very bad idea...)

 —Claude
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

[Tom Boutell]

> Can someone tell me exactly how just omitting "await" doesn't broadly
achieve the "concurrency" objective?

Omitting "await" gives us no assurance that all of the iterations completed
prior to exit from the "for...of" loop.

My proposal should have specified that regardless of whether "concurrency
N" or "concurrent" is used, the loop will not exit until all of the items
have successfully executed the loop body.

> It could be probably added as a Promise.all(iterable, concurrency?)

While this would be a useful extension to Promise.all and might be part of
the underlying implementation of the language feature, this does not meet
the goal of avoiding the cognitive load of shifting gears from the
"async/await" pattern to thinking overtly about promises. There are similar
implementations, such as the one in Bluebird, but the goal of the language
feature is to expand the set of problems that can be solved without the
cognitive load of collecting async function return values and then awaiting
a library function that operates on them.

My own belief is that the percentage of "await-friendly" use cases for
asynchronous programming that come up for most developers is pretty close
to 90%, and that a syntax for specifying concurrency would take it the rest
of the way there, and be much appreciated by the developer who has written
the "for...of { await ... }" loop and now wants to improve the performance
in a simple way that is also likely to be safe (bounded concurrency).

--
Chief Software Architect
Apostrophe Technologies
Pronouns: he / him / his
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

[Naveen Chawla]

Can someone tell me exactly how just omitting "await" doesn't broadly
achieve the "concurrency" objective?

On Fri, 6 Sep 2019, 20:04 Cyril Auburtin,  wrote:

> It could be probably added as a `Promise.all(iterable, concurrency?)`
>
> Some existing implementations:
> - http://bluebirdjs.com/docs/api/promise.map.html
> - https://caolan.github.io/async/v3/docs.html#mapLimit
> - I tried to write one:
> https://github.com/caub/misc/blob/master/utils/promise-concurrent.js
>
> On Fri, Sep 6, 2019 at 8:33 PM Tom Boutell  wrote:
>
>> I am more interested in syntax two than syntax one, which I felt should
>> probably be included for completeness. But hey, as you say, maybe not since
>> unguarded concurrency is indeed usually a mistake.
>>
>> Taken on its own, do you have an objection to `for (item of items
>> concurrency 5) { ... }`?
>>
>>
>> On Fri, Sep 6, 2019 at 1:46 PM C. Scott Ananian 
>> wrote:
>>
>>> The current way to write what you want is:
>>>
>>> await Promise.all(itemsCursor.map(item => db.insert(item));
>>>
>>> or
>>>
>>> await Promise.all(itemsCursor.map(Promise.guard(5, item =>
>>> db.insert(item;
>>>
>>> if you are using a library like `prfun` (
>>> https://github.com/cscott/prfun#promiseguardfunctionnumber-condition-function-fn--function
>>> ).
>>>
>>> I'm not sure adding a new parallel loop construct is an obvious
>>> improvement on this, especially since unguarded concurrent execution is
>>> usually a mistake (can cause memory requirements to blow up), as you point
>>> out yourself.
>>>
>>> I'd be more in favor of new syntax if it was integrated with a
>>> work-stealing mechanism, since (a) that can't as easily be done in a
>>> library function (you need access to the entire set of runnable tasks, not
>>> just the ones created in this loop), and (b) is more likely to be
>>> correct/fast by default and not lead to subtle resource-exhaustion problems.
>>>   --scott
>>>
>>> On Fri, Sep 6, 2019 at 12:40 PM Tom Boutell 
>>> wrote:
>>>
 *Specifying concurrency for "for...of" loops potentially containing
 "await" statements in the loop body*

 In the async/await era, I see most developers using the async and await
 keywords in 90% of situations, shifting to "Promise.all" or the bluebird
 library only to cope with concurrency issues.

 The most common case in my experience is the need to admit a manageable
 level of parallelism when iterating a large array (or iterator, see the
 final section) and performing asynchronous work on each item. Unlimited
 concurrency (Promise.all) tends to overwhelm backends involved in a way
 that confuses developers as to what is happening. Bluebird's "Promise.map"
 permits concurrency to be specified, which is great, but requires pulling
 in a library and switching of mental gears ("OK right, these async
 functions return promises," etc).

 To build on the friendliness of async/await, I propose these two
 syntaxes be accepted:

 SYNTAX ONE

 ```js
 for (item of items concurrent) {
   // db.insert is an async function
   await db.insert(item);
 }
 ```

 In Syntax One, all loop bodies commence concurrently (see below for the
 definition of "concurrently" with regard to async). If an exception is not
 caught inside the loop, it is thrown beyond the loop, and all exceptions
 subsequently thrown by concurrently executing loop bodies are discarded
 (like Promise.all).

 *While I feel that unlimited concurrency is usually a mistake in a
 situation where you have an array of items of unpredictable number, it
 seems odd not to have a syntax for this case, and "concurrency 0" seems
 clunky.*

 SYNTAX TWO

 ```js
 for (item of items concurrency 5) {
   // db.insert is an async function
   await db.insert(item);
 }
 ```

 in Syntax Two, up to 5 loop bodies commence concurrently (see below).
 There is no guarantee that item 3 will finish before item 2, or that item 4
 won't start (due to 3 being finished) before item 2 ends, etc. If an
 exception is not caught inside the loop, it is thrown beyond the loop, and
 all exceptions subsequently thrown by concurrently executing loop bodies
 are discarded (like Promise.all in this respect, except for the restriction
 of concurrency).

 DEFINING CONCURRENCY FOR ASYNC

 For purposes of this proposal, "concurrent" execution means that
 multiple loop bodies may be suspended via "await" at any given time. It
 does NOT refer to multithreaded execution, worker threads, etc.

 CONSIDERATIONS FOR ASYNC ITERATORS

 Async iterator syntax for "for...of" loops, as in:

 ```js
 for await (item of itemsCursor) { ... }
 ```

 Should also support concurrency for the loop body, with the same syntax:

 ```js
 for await (item of itemsCursor concurrency 5) { ... }
 

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

[Michael J. Ryan]

With the promise.all, would each item in the iterable be an async function
(or function returning a promise)?  I mean, I'm presuming the point is to
not have every item execute at the same time.

-- 

Michael J. Ryan
Website: https://www.tracker1.info/
Email: track...@gmail.com
Mobile: 480-270-4509


On Fri, Sep 6, 2019 at 12:04 PM Cyril Auburtin 
wrote:

> It could be probably added as a `Promise.all(iterable, concurrency?)`
>
> Some existing implementations:
> - http://bluebirdjs.com/docs/api/promise.map.html
> - https://caolan.github.io/async/v3/docs.html#mapLimit
> - I tried to write one:
> https://github.com/caub/misc/blob/master/utils/promise-concurrent.js
>
> On Fri, Sep 6, 2019 at 8:33 PM Tom Boutell  wrote:
>
>> I am more interested in syntax two than syntax one, which I felt should
>> probably be included for completeness. But hey, as you say, maybe not since
>> unguarded concurrency is indeed usually a mistake.
>>
>> Taken on its own, do you have an objection to `for (item of items
>> concurrency 5) { ... }`?
>>
>>
>> On Fri, Sep 6, 2019 at 1:46 PM C. Scott Ananian 
>> wrote:
>>
>>> The current way to write what you want is:
>>>
>>> await Promise.all(itemsCursor.map(item => db.insert(item));
>>>
>>> or
>>>
>>> await Promise.all(itemsCursor.map(Promise.guard(5, item =>
>>> db.insert(item;
>>>
>>> if you are using a library like `prfun` (
>>> https://github.com/cscott/prfun#promiseguardfunctionnumber-condition-function-fn--function
>>> ).
>>>
>>> I'm not sure adding a new parallel loop construct is an obvious
>>> improvement on this, especially since unguarded concurrent execution is
>>> usually a mistake (can cause memory requirements to blow up), as you point
>>> out yourself.
>>>
>>> I'd be more in favor of new syntax if it was integrated with a
>>> work-stealing mechanism, since (a) that can't as easily be done in a
>>> library function (you need access to the entire set of runnable tasks, not
>>> just the ones created in this loop), and (b) is more likely to be
>>> correct/fast by default and not lead to subtle resource-exhaustion problems.
>>>   --scott
>>>
>>> On Fri, Sep 6, 2019 at 12:40 PM Tom Boutell 
>>> wrote:
>>>
 *Specifying concurrency for "for...of" loops potentially containing
 "await" statements in the loop body*

 In the async/await era, I see most developers using the async and await
 keywords in 90% of situations, shifting to "Promise.all" or the bluebird
 library only to cope with concurrency issues.

 The most common case in my experience is the need to admit a manageable
 level of parallelism when iterating a large array (or iterator, see the
 final section) and performing asynchronous work on each item. Unlimited
 concurrency (Promise.all) tends to overwhelm backends involved in a way
 that confuses developers as to what is happening. Bluebird's "Promise.map"
 permits concurrency to be specified, which is great, but requires pulling
 in a library and switching of mental gears ("OK right, these async
 functions return promises," etc).

 To build on the friendliness of async/await, I propose these two
 syntaxes be accepted:

 SYNTAX ONE

 ```js
 for (item of items concurrent) {
   // db.insert is an async function
   await db.insert(item);
 }
 ```

 In Syntax One, all loop bodies commence concurrently (see below for the
 definition of "concurrently" with regard to async). If an exception is not
 caught inside the loop, it is thrown beyond the loop, and all exceptions
 subsequently thrown by concurrently executing loop bodies are discarded
 (like Promise.all).

 *While I feel that unlimited concurrency is usually a mistake in a
 situation where you have an array of items of unpredictable number, it
 seems odd not to have a syntax for this case, and "concurrency 0" seems
 clunky.*

 SYNTAX TWO

 ```js
 for (item of items concurrency 5) {
   // db.insert is an async function
   await db.insert(item);
 }
 ```

 in Syntax Two, up to 5 loop bodies commence concurrently (see below).
 There is no guarantee that item 3 will finish before item 2, or that item 4
 won't start (due to 3 being finished) before item 2 ends, etc. If an
 exception is not caught inside the loop, it is thrown beyond the loop, and
 all exceptions subsequently thrown by concurrently executing loop bodies
 are discarded (like Promise.all in this respect, except for the restriction
 of concurrency).

 DEFINING CONCURRENCY FOR ASYNC

 For purposes of this proposal, "concurrent" execution means that
 multiple loop bodies may be suspended via "await" at any given time. It
 does NOT refer to multithreaded execution, worker threads, etc.

 CONSIDERATIONS FOR ASYNC ITERATORS

 Async iterator syntax for "for...of" loops, as in:

 ```js
 for await 

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

[Cyril Auburtin]

It could be probably added as a `Promise.all(iterable, concurrency?)`

Some existing implementations:
- http://bluebirdjs.com/docs/api/promise.map.html
- https://caolan.github.io/async/v3/docs.html#mapLimit
- I tried to write one:
https://github.com/caub/misc/blob/master/utils/promise-concurrent.js

On Fri, Sep 6, 2019 at 8:33 PM Tom Boutell  wrote:

> I am more interested in syntax two than syntax one, which I felt should
> probably be included for completeness. But hey, as you say, maybe not since
> unguarded concurrency is indeed usually a mistake.
>
> Taken on its own, do you have an objection to `for (item of items
> concurrency 5) { ... }`?
>
>
> On Fri, Sep 6, 2019 at 1:46 PM C. Scott Ananian 
> wrote:
>
>> The current way to write what you want is:
>>
>> await Promise.all(itemsCursor.map(item => db.insert(item));
>>
>> or
>>
>> await Promise.all(itemsCursor.map(Promise.guard(5, item =>
>> db.insert(item;
>>
>> if you are using a library like `prfun` (
>> https://github.com/cscott/prfun#promiseguardfunctionnumber-condition-function-fn--function
>> ).
>>
>> I'm not sure adding a new parallel loop construct is an obvious
>> improvement on this, especially since unguarded concurrent execution is
>> usually a mistake (can cause memory requirements to blow up), as you point
>> out yourself.
>>
>> I'd be more in favor of new syntax if it was integrated with a
>> work-stealing mechanism, since (a) that can't as easily be done in a
>> library function (you need access to the entire set of runnable tasks, not
>> just the ones created in this loop), and (b) is more likely to be
>> correct/fast by default and not lead to subtle resource-exhaustion problems.
>>   --scott
>>
>> On Fri, Sep 6, 2019 at 12:40 PM Tom Boutell 
>> wrote:
>>
>>> *Specifying concurrency for "for...of" loops potentially containing
>>> "await" statements in the loop body*
>>>
>>> In the async/await era, I see most developers using the async and await
>>> keywords in 90% of situations, shifting to "Promise.all" or the bluebird
>>> library only to cope with concurrency issues.
>>>
>>> The most common case in my experience is the need to admit a manageable
>>> level of parallelism when iterating a large array (or iterator, see the
>>> final section) and performing asynchronous work on each item. Unlimited
>>> concurrency (Promise.all) tends to overwhelm backends involved in a way
>>> that confuses developers as to what is happening. Bluebird's "Promise.map"
>>> permits concurrency to be specified, which is great, but requires pulling
>>> in a library and switching of mental gears ("OK right, these async
>>> functions return promises," etc).
>>>
>>> To build on the friendliness of async/await, I propose these two
>>> syntaxes be accepted:
>>>
>>> SYNTAX ONE
>>>
>>> ```js
>>> for (item of items concurrent) {
>>>   // db.insert is an async function
>>>   await db.insert(item);
>>> }
>>> ```
>>>
>>> In Syntax One, all loop bodies commence concurrently (see below for the
>>> definition of "concurrently" with regard to async). If an exception is not
>>> caught inside the loop, it is thrown beyond the loop, and all exceptions
>>> subsequently thrown by concurrently executing loop bodies are discarded
>>> (like Promise.all).
>>>
>>> *While I feel that unlimited concurrency is usually a mistake in a
>>> situation where you have an array of items of unpredictable number, it
>>> seems odd not to have a syntax for this case, and "concurrency 0" seems
>>> clunky.*
>>>
>>> SYNTAX TWO
>>>
>>> ```js
>>> for (item of items concurrency 5) {
>>>   // db.insert is an async function
>>>   await db.insert(item);
>>> }
>>> ```
>>>
>>> in Syntax Two, up to 5 loop bodies commence concurrently (see below).
>>> There is no guarantee that item 3 will finish before item 2, or that item 4
>>> won't start (due to 3 being finished) before item 2 ends, etc. If an
>>> exception is not caught inside the loop, it is thrown beyond the loop, and
>>> all exceptions subsequently thrown by concurrently executing loop bodies
>>> are discarded (like Promise.all in this respect, except for the restriction
>>> of concurrency).
>>>
>>> DEFINING CONCURRENCY FOR ASYNC
>>>
>>> For purposes of this proposal, "concurrent" execution means that
>>> multiple loop bodies may be suspended via "await" at any given time. It
>>> does NOT refer to multithreaded execution, worker threads, etc.
>>>
>>> CONSIDERATIONS FOR ASYNC ITERATORS
>>>
>>> Async iterator syntax for "for...of" loops, as in:
>>>
>>> ```js
>>> for await (item of itemsCursor) { ... }
>>> ```
>>>
>>> Should also support concurrency for the loop body, with the same syntax:
>>>
>>> ```js
>>> for await (item of itemsCursor concurrency 5) { ... }
>>> ```
>>>
>>> *It is important to note that this syntax does not add concurrency to
>>> the async iterator itself, *at least not at this time, as I believe the
>>> interface for defining async iterators does not currently accommodate this.
>>> However this syntax is still useful because it 

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

[Tom Boutell]

I am more interested in syntax two than syntax one, which I felt should
probably be included for completeness. But hey, as you say, maybe not since
unguarded concurrency is indeed usually a mistake.

Taken on its own, do you have an objection to `for (item of items
concurrency 5) { ... }`?


On Fri, Sep 6, 2019 at 1:46 PM C. Scott Ananian 
wrote:

> The current way to write what you want is:
>
> await Promise.all(itemsCursor.map(item => db.insert(item));
>
> or
>
> await Promise.all(itemsCursor.map(Promise.guard(5, item =>
> db.insert(item;
>
> if you are using a library like `prfun` (
> https://github.com/cscott/prfun#promiseguardfunctionnumber-condition-function-fn--function
> ).
>
> I'm not sure adding a new parallel loop construct is an obvious
> improvement on this, especially since unguarded concurrent execution is
> usually a mistake (can cause memory requirements to blow up), as you point
> out yourself.
>
> I'd be more in favor of new syntax if it was integrated with a
> work-stealing mechanism, since (a) that can't as easily be done in a
> library function (you need access to the entire set of runnable tasks, not
> just the ones created in this loop), and (b) is more likely to be
> correct/fast by default and not lead to subtle resource-exhaustion problems.
>   --scott
>
> On Fri, Sep 6, 2019 at 12:40 PM Tom Boutell  wrote:
>
>> *Specifying concurrency for "for...of" loops potentially containing
>> "await" statements in the loop body*
>>
>> In the async/await era, I see most developers using the async and await
>> keywords in 90% of situations, shifting to "Promise.all" or the bluebird
>> library only to cope with concurrency issues.
>>
>> The most common case in my experience is the need to admit a manageable
>> level of parallelism when iterating a large array (or iterator, see the
>> final section) and performing asynchronous work on each item. Unlimited
>> concurrency (Promise.all) tends to overwhelm backends involved in a way
>> that confuses developers as to what is happening. Bluebird's "Promise.map"
>> permits concurrency to be specified, which is great, but requires pulling
>> in a library and switching of mental gears ("OK right, these async
>> functions return promises," etc).
>>
>> To build on the friendliness of async/await, I propose these two syntaxes
>> be accepted:
>>
>> SYNTAX ONE
>>
>> ```js
>> for (item of items concurrent) {
>>   // db.insert is an async function
>>   await db.insert(item);
>> }
>> ```
>>
>> In Syntax One, all loop bodies commence concurrently (see below for the
>> definition of "concurrently" with regard to async). If an exception is not
>> caught inside the loop, it is thrown beyond the loop, and all exceptions
>> subsequently thrown by concurrently executing loop bodies are discarded
>> (like Promise.all).
>>
>> *While I feel that unlimited concurrency is usually a mistake in a
>> situation where you have an array of items of unpredictable number, it
>> seems odd not to have a syntax for this case, and "concurrency 0" seems
>> clunky.*
>>
>> SYNTAX TWO
>>
>> ```js
>> for (item of items concurrency 5) {
>>   // db.insert is an async function
>>   await db.insert(item);
>> }
>> ```
>>
>> in Syntax Two, up to 5 loop bodies commence concurrently (see below).
>> There is no guarantee that item 3 will finish before item 2, or that item 4
>> won't start (due to 3 being finished) before item 2 ends, etc. If an
>> exception is not caught inside the loop, it is thrown beyond the loop, and
>> all exceptions subsequently thrown by concurrently executing loop bodies
>> are discarded (like Promise.all in this respect, except for the restriction
>> of concurrency).
>>
>> DEFINING CONCURRENCY FOR ASYNC
>>
>> For purposes of this proposal, "concurrent" execution means that multiple
>> loop bodies may be suspended via "await" at any given time. It does NOT
>> refer to multithreaded execution, worker threads, etc.
>>
>> CONSIDERATIONS FOR ASYNC ITERATORS
>>
>> Async iterator syntax for "for...of" loops, as in:
>>
>> ```js
>> for await (item of itemsCursor) { ... }
>> ```
>>
>> Should also support concurrency for the loop body, with the same syntax:
>>
>> ```js
>> for await (item of itemsCursor concurrency 5) { ... }
>> ```
>>
>> *It is important to note that this syntax does not add concurrency to the
>> async iterator itself, *at least not at this time, as I believe the
>> interface for defining async iterators does not currently accommodate this.
>> However this syntax is still useful because it *fetches the items
>> sequentially from the iterator, but may "fill the hopper" with up to five
>> iterator results* that are currently being actively processed by loop
>> bodies. In many cases, fetching items via an iterator is much faster than
>> the processing that will be done to them in the loop bodies, and so this is
>> still useful.
>>
>> Thanks for reading!
>>
>> --
>> Chief Software Architect
>> Apostrophe Technologies
>> Pronouns: he / him / his
>> 

Re: [Proposal] Refer to actual value : keyword "itself"

[Jordan Harband]

`var itself = 3;` means that your choice of keyword wouldn't be an option;
you'd be limited to something that was currently a syntax error.

On Fri, Sep 6, 2019 at 2:53 AM Cyril Auburtin 
wrote:

> also optional-chaining will help
> ```js
> return {
> ...state,
> child: {
> ...state?.child,
> subchild: {
> ...state?.child?.subchild,
> property: (state?.child?.subchild?.property ?? 0) + 1
> }
> }
> }
> ```
>
> @Herby yes that's interesting, works in any order actually `const {child,
> child: {subchild}} = state;`
>
> On Fri, Sep 6, 2019 at 11:23 AM Herby Vojčík  wrote:
>
>> On 6. 9. 2019 10:34, Cyril Auburtin wrote:
>> > You could currently do
>> > ```js
>> > object.child.property /= 5
>> > ```
>> >
>> > with destructuring:
>> > ```js
>> > const {child: {subchild}, child} = state;
>>
>> Wow, I didn't know I can do that. Nice.
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Jordan Harband]

Syntactically marking, in a chain, what you'd like the final value of the
chain to be, seems interesting - forcing optionality into it seems
unnecessary, though, if such a syntactic marker could be attached to all
forms of property access.

Something like: `a.b>.c.d` or `a?.b>?.c?.d` or `a>[b][c][d]`.

(Obviously, the `>` won't work with bracket, and any syntax for normal
properties that only applies to dot and not also bracket would somewhat be
a nonstarter; but the specific syntax can be bikeshedded separately)

On Fri, Sep 6, 2019 at 8:04 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Indeed I'm not super convinced myself about the "branching issue" 'cause
> `const result = this?.is?.branching?.already` and all I am proposing is to
> hint the syntax where to stop in case something else fails down the line,
> as in `const result = this.?.is part is not reached, there is a certain point to keep going (which is,
> example, checking that `result !== this`)
>
> On Fri, Sep 6, 2019 at 4:17 PM Naveen Chawla 
> wrote:
>
>> Typically, "dot" expressions navigate through values of different types,
>> making "type branching" the inevitable next step in those cases (unless you
>> introduce a common method for further processing for each of those types).
>> So I'm not sure how ultimately that would be avoided.
>>
>> On Fri, 6 Sep 2019 at 14:15, Claude Pache  wrote:
>>
>>>
>>>
>>> Le 6 sept. 2019 à 14:35, Felipe Nascimento de Moura <
>>> felipenmo...@gmail.com> a écrit :
>>>
>>> Doesn't that bring risks to breaking the web?
>>>
>>> You seen, many, MANY servers running php have the "shot-tags" feature
>>> enabled, in which pages with  will be interpreted.
>>> In this case, any html page with embedded scripts using this operator,
>>> or event .js files when the server is configured to also run php in them,
>>> will break.
>>>
>>> Or am I missing something here?
>>>
>>> [ ]s
>>>
>>>
>>> Any future PHP file that incorporate that syntax will almost surely
>>> refuse to compile on servers that has short-tags enabled, making the
>>> problem evident before it produces something useful on the web. This may be
>>> an issue, but this is not what “breaking the web” is intended to mean.
>>> Existing, untouched content will not break. Carelessly updated content
>>> might break, but that’s not fundamentally different from any other careless
>>> update.
>>>
>>> (If anything else, it may convince people that having different
>>> configuration settings w.r.t. short-tags in development environment and in
>>> production environment, is a very bad idea...)
>>>
>>> —Claude
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

[C. Scott Ananian]

The current way to write what you want is:

await Promise.all(itemsCursor.map(item => db.insert(item));

or

await Promise.all(itemsCursor.map(Promise.guard(5, item =>
db.insert(item;

if you are using a library like `prfun` (
https://github.com/cscott/prfun#promiseguardfunctionnumber-condition-function-fn--function
).

I'm not sure adding a new parallel loop construct is an obvious improvement
on this, especially since unguarded concurrent execution is usually a
mistake (can cause memory requirements to blow up), as you point out
yourself.

I'd be more in favor of new syntax if it was integrated with a
work-stealing mechanism, since (a) that can't as easily be done in a
library function (you need access to the entire set of runnable tasks, not
just the ones created in this loop), and (b) is more likely to be
correct/fast by default and not lead to subtle resource-exhaustion problems.
  --scott

On Fri, Sep 6, 2019 at 12:40 PM Tom Boutell  wrote:

> *Specifying concurrency for "for...of" loops potentially containing
> "await" statements in the loop body*
>
> In the async/await era, I see most developers using the async and await
> keywords in 90% of situations, shifting to "Promise.all" or the bluebird
> library only to cope with concurrency issues.
>
> The most common case in my experience is the need to admit a manageable
> level of parallelism when iterating a large array (or iterator, see the
> final section) and performing asynchronous work on each item. Unlimited
> concurrency (Promise.all) tends to overwhelm backends involved in a way
> that confuses developers as to what is happening. Bluebird's "Promise.map"
> permits concurrency to be specified, which is great, but requires pulling
> in a library and switching of mental gears ("OK right, these async
> functions return promises," etc).
>
> To build on the friendliness of async/await, I propose these two syntaxes
> be accepted:
>
> SYNTAX ONE
>
> ```js
> for (item of items concurrent) {
>   // db.insert is an async function
>   await db.insert(item);
> }
> ```
>
> In Syntax One, all loop bodies commence concurrently (see below for the
> definition of "concurrently" with regard to async). If an exception is not
> caught inside the loop, it is thrown beyond the loop, and all exceptions
> subsequently thrown by concurrently executing loop bodies are discarded
> (like Promise.all).
>
> *While I feel that unlimited concurrency is usually a mistake in a
> situation where you have an array of items of unpredictable number, it
> seems odd not to have a syntax for this case, and "concurrency 0" seems
> clunky.*
>
> SYNTAX TWO
>
> ```js
> for (item of items concurrency 5) {
>   // db.insert is an async function
>   await db.insert(item);
> }
> ```
>
> in Syntax Two, up to 5 loop bodies commence concurrently (see below).
> There is no guarantee that item 3 will finish before item 2, or that item 4
> won't start (due to 3 being finished) before item 2 ends, etc. If an
> exception is not caught inside the loop, it is thrown beyond the loop, and
> all exceptions subsequently thrown by concurrently executing loop bodies
> are discarded (like Promise.all in this respect, except for the restriction
> of concurrency).
>
> DEFINING CONCURRENCY FOR ASYNC
>
> For purposes of this proposal, "concurrent" execution means that multiple
> loop bodies may be suspended via "await" at any given time. It does NOT
> refer to multithreaded execution, worker threads, etc.
>
> CONSIDERATIONS FOR ASYNC ITERATORS
>
> Async iterator syntax for "for...of" loops, as in:
>
> ```js
> for await (item of itemsCursor) { ... }
> ```
>
> Should also support concurrency for the loop body, with the same syntax:
>
> ```js
> for await (item of itemsCursor concurrency 5) { ... }
> ```
>
> *It is important to note that this syntax does not add concurrency to the
> async iterator itself, *at least not at this time, as I believe the
> interface for defining async iterators does not currently accommodate this.
> However this syntax is still useful because it *fetches the items
> sequentially from the iterator, but may "fill the hopper" with up to five
> iterator results* that are currently being actively processed by loop
> bodies. In many cases, fetching items via an iterator is much faster than
> the processing that will be done to them in the loop bodies, and so this is
> still useful.
>
> Thanks for reading!
>
> --
> Chief Software Architect
> Apostrophe Technologies
> Pronouns: he / him / his
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Stage 0 proposal: specifying concurrency for "for...of" loops potentially containing "await" statements

[Tom Boutell]

*Specifying concurrency for "for...of" loops potentially containing "await"
statements in the loop body*

In the async/await era, I see most developers using the async and await
keywords in 90% of situations, shifting to "Promise.all" or the bluebird
library only to cope with concurrency issues.

The most common case in my experience is the need to admit a manageable
level of parallelism when iterating a large array (or iterator, see the
final section) and performing asynchronous work on each item. Unlimited
concurrency (Promise.all) tends to overwhelm backends involved in a way
that confuses developers as to what is happening. Bluebird's "Promise.map"
permits concurrency to be specified, which is great, but requires pulling
in a library and switching of mental gears ("OK right, these async
functions return promises," etc).

To build on the friendliness of async/await, I propose these two syntaxes
be accepted:

SYNTAX ONE

```js
for (item of items concurrent) {
  // db.insert is an async function
  await db.insert(item);
}
```

In Syntax One, all loop bodies commence concurrently (see below for the
definition of "concurrently" with regard to async). If an exception is not
caught inside the loop, it is thrown beyond the loop, and all exceptions
subsequently thrown by concurrently executing loop bodies are discarded
(like Promise.all).

*While I feel that unlimited concurrency is usually a mistake in a
situation where you have an array of items of unpredictable number, it
seems odd not to have a syntax for this case, and "concurrency 0" seems
clunky.*

SYNTAX TWO

```js
for (item of items concurrency 5) {
  // db.insert is an async function
  await db.insert(item);
}
```

in Syntax Two, up to 5 loop bodies commence concurrently (see below). There
is no guarantee that item 3 will finish before item 2, or that item 4 won't
start (due to 3 being finished) before item 2 ends, etc. If an exception is
not caught inside the loop, it is thrown beyond the loop, and all
exceptions subsequently thrown by concurrently executing loop bodies are
discarded (like Promise.all in this respect, except for the restriction of
concurrency).

DEFINING CONCURRENCY FOR ASYNC

For purposes of this proposal, "concurrent" execution means that multiple
loop bodies may be suspended via "await" at any given time. It does NOT
refer to multithreaded execution, worker threads, etc.

CONSIDERATIONS FOR ASYNC ITERATORS

Async iterator syntax for "for...of" loops, as in:

```js
for await (item of itemsCursor) { ... }
```

Should also support concurrency for the loop body, with the same syntax:

```js
for await (item of itemsCursor concurrency 5) { ... }
```

*It is important to note that this syntax does not add concurrency to the
async iterator itself, *at least not at this time, as I believe the
interface for defining async iterators does not currently accommodate this.
However this syntax is still useful because it *fetches the items
sequentially from the iterator, but may "fill the hopper" with up to five
iterator results* that are currently being actively processed by loop
bodies. In many cases, fetching items via an iterator is much faster than
the processing that will be done to them in the loop bodies, and so this is
still useful.

Thanks for reading!

-- 
Chief Software Architect
Apostrophe Technologies
Pronouns: he / him / his
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Andrea Giammarchi]

Indeed I'm not super convinced myself about the "branching issue" 'cause
`const result = this?.is?.branching?.already` and all I am proposing is to
hint the syntax where to stop in case something else fails down the line,
as in `const result = this.?.is wrote:

> Typically, "dot" expressions navigate through values of different types,
> making "type branching" the inevitable next step in those cases (unless you
> introduce a common method for further processing for each of those types).
> So I'm not sure how ultimately that would be avoided.
>
> On Fri, 6 Sep 2019 at 14:15, Claude Pache  wrote:
>
>>
>>
>> Le 6 sept. 2019 à 14:35, Felipe Nascimento de Moura <
>> felipenmo...@gmail.com> a écrit :
>>
>> Doesn't that bring risks to breaking the web?
>>
>> You seen, many, MANY servers running php have the "shot-tags" feature
>> enabled, in which pages with  will be interpreted.
>> In this case, any html page with embedded scripts using this operator, or
>> event .js files when the server is configured to also run php in them, will
>> break.
>>
>> Or am I missing something here?
>>
>> [ ]s
>>
>>
>> Any future PHP file that incorporate that syntax will almost surely
>> refuse to compile on servers that has short-tags enabled, making the
>> problem evident before it produces something useful on the web. This may be
>> an issue, but this is not what “breaking the web” is intended to mean.
>> Existing, untouched content will not break. Carelessly updated content
>> might break, but that’s not fundamentally different from any other careless
>> update.
>>
>> (If anything else, it may convince people that having different
>> configuration settings w.r.t. short-tags in development environment and in
>> production environment, is a very bad idea...)
>>
>> —Claude
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Naveen Chawla]

Typically, "dot" expressions navigate through values of different types,
making "type branching" the inevitable next step in those cases (unless you
introduce a common method for further processing for each of those types).
So I'm not sure how ultimately that would be avoided.

On Fri, 6 Sep 2019 at 14:15, Claude Pache  wrote:

>
>
> Le 6 sept. 2019 à 14:35, Felipe Nascimento de Moura <
> felipenmo...@gmail.com> a écrit :
>
> Doesn't that bring risks to breaking the web?
>
> You seen, many, MANY servers running php have the "shot-tags" feature
> enabled, in which pages with  will be interpreted.
> In this case, any html page with embedded scripts using this operator, or
> event .js files when the server is configured to also run php in them, will
> break.
>
> Or am I missing something here?
>
> [ ]s
>
>
> Any future PHP file that incorporate that syntax will almost surely refuse
> to compile on servers that has short-tags enabled, making the problem
> evident before it produces something useful on the web. This may be an
> issue, but this is not what “breaking the web” is intended to mean.
> Existing, untouched content will not break. Carelessly updated content
> might break, but that’s not fundamentally different from any other careless
> update.
>
> (If anything else, it may convince people that having different
> configuration settings w.r.t. short-tags in development environment and in
> production environment, is a very bad idea...)
>
> —Claude
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Claude Pache]

> Le 6 sept. 2019 à 14:35, Felipe Nascimento de Moura  
> a écrit :
> 
> Doesn't that bring risks to breaking the web?
> 
> You seen, many, MANY servers running php have the "shot-tags" feature 
> enabled, in which pages with  will be interpreted.
> In this case, any html page with embedded scripts using this operator, or 
> event .js files when the server is configured to also run php in them, will 
> break.
> 
> Or am I missing something here?
> 
> [ ]s
> 

Any future PHP file that incorporate that syntax will almost surely refuse to 
compile on servers that has short-tags enabled, making the problem evident 
before it produces something useful on the web. This may be an issue, but this 
is not what “breaking the web” is intended to mean. Existing, untouched content 
will not break. Carelessly updated content might break, but that’s not 
fundamentally different from any other careless update.

(If anything else, it may convince people that having different configuration 
settings w.r.t. short-tags in development environment and in production 
environment, is a very bad idea...)

—Claude___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Andrea Giammarchi]

You keep diverging from the intent, basing your answers on my quick'n'dirty
examples. I agree my examples are probably not the best looking, but there
are no solutions right now to retrieve one part of th echain that failed,
if not repeating the chain, and eventually thesame errors, on the right
hand side.

This is what `https://github.com/WebReflection/mice.trap#readme

On Fri, Sep 6, 2019 at 2:48 PM Naveen Chawla  wrote:

>
> I'm not in TC39, sorry if I sounded like I was, just voicing my opinion.
>
> I think the example you gave is better served by throwing the exception
> from inside "query", instead of doing a "typeof" with the proposed operator
> afterward.
>
> I find "type branching" normally to be a cumbersome logical flow.
> Ordinarily the branching can be factored into a common "method" between the
> types, so that logical flow doesn't need the branching at all (the method
> "override" does it for you), but in the case of a "mouse" operator, you
> could often be dealing with completely different types, for which a "common
> method" may not make sense in the logical flow, thereby necessitating the
> "type branching" featured in all your examples so far.
>
> To me "type branching" is a non-communicative style of programming. The
> reader may not know the exact "type" of a particular property or
> method/function's return value, even more so in JavaScript. Even worse if
> the method may return different types depending on conditions. It is this
> lack of clarity that I think can introduce bugs. The remedy, in my mind, is
> a consistent (non-branching) logical flow. I think that language constructs
> should encourage that type of programming and discourage type branching
> (and other patterns that risk having a lack of logical clarity).
>
> Just my opinion, as I said. Disagreements welcome.
>
> On Fri, 6 Sep 2019 at 08:59, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> The purpose is to address what chaining lacks, in terms of "stopping" at
>> some point whenever it's available or not.
>>
>> Take this example:
>>
>> ```js
>> // the current chaining operator
>> const result = nmsp.some.payload()?.result ?? nmsp.some.payload();
>>
>> // the mouse operator
>> const result = nmsp.some.payload()> ```
>>
>> Keeping it semantic, the mouse operator is "a trap" for the chain that
>> makes reading possible expensive parts of the chain easier. An utility to
>> obtain the same code would look something like the following:
>>
>> ```js
>> // the mouse utility
>> const mouse = trap => {
>>   // a way to self clean right after, as it is for RegExp.$* values
>>   // which is something impossible to obtain with regular syntax
>>   Promise.resolve(mouse.trap = trap).then(() => delete mouse.trap);
>>   return trap;
>> };
>>
>> // the previous example
>> const result = mouse(nmsp.some.payload())?.result ?? mouse.trap;
>> ```
>>
>> Since there is no easy way to syntactically obtain the same with the
>> current `?` and `??` without repeating all steps in the right side of the
>> `??`, I've thought this "mouse operator" would play a role to actually
>> avoid bugs easily introduced by repeating calls on the right hand side of
>> the `??` either via getters or expensive operations.
>>
>> It is also possible to keep going on a chain or eventually provide
>> feedbacks of what went wrong:
>>
>> ```js
>> const name = await some.query(id)> if (typeof name !== 'string')
>>   throw name;
>> ```
>>
>> As summary, considering how semantic it's the operator in both visual and
>> practical meanings, and considering it's not possible to achieve the same
>> result through `??`, I wish it would be considered as complementary help
>> for the recently introduced `?.` and `??` syntax.
>>
>> So thanks in advance for possible consideration.
>>
>> Regards
>>
>>
>> On Fri, Sep 6, 2019 at 9:14 AM Naveen Chawla 
>> wrote:
>>
>>> I think introducing this operator encourages bad logic design like
>>> "instanceof", isArray etc. These are unreadable disambiguation factors in
>>> that they don't inform about which part the expression is going to the next
>>> stage in the process. Also it leads to "type branching", which tends
>>> towards more convoluted logical flow. These things, in my mind, would lead
>>> to more bugs. Hence I would tend to be against introducing it, especially
>>> in light of other proposals that I find more useful that haven't been taken
>>> even to discussion.
>>>
>>> On Fri, 6 Sep 2019, 07:58 Claude Pache,  wrote:
>>>


 Le 5 sept. 2019 à 23:39, Andrea Giammarchi 
 a écrit :

 This is basically a solution to a common problem we have these days,
 where modules published in the wild might have a `default` property, to
 support ESM logic, or not.

 ```js
 // current optional chaining logic
 const imported = exported?.default ?? exported;

 // my "mice operator" proposal
 const imported = exported>>> ```



 The semantics of the `?.` in 

Re: Optional chaining syntax but with the "mice" operator ?

[Naveen Chawla]

I'm not in TC39, sorry if I sounded like I was, just voicing my opinion.

I think the example you gave is better served by throwing the exception
from inside "query", instead of doing a "typeof" with the proposed operator
afterward.

I find "type branching" normally to be a cumbersome logical flow.
Ordinarily the branching can be factored into a common "method" between the
types, so that logical flow doesn't need the branching at all (the method
"override" does it for you), but in the case of a "mouse" operator, you
could often be dealing with completely different types, for which a "common
method" may not make sense in the logical flow, thereby necessitating the
"type branching" featured in all your examples so far.

To me "type branching" is a non-communicative style of programming. The
reader may not know the exact "type" of a particular property or
method/function's return value, even more so in JavaScript. Even worse if
the method may return different types depending on conditions. It is this
lack of clarity that I think can introduce bugs. The remedy, in my mind, is
a consistent (non-branching) logical flow. I think that language constructs
should encourage that type of programming and discourage type branching
(and other patterns that risk having a lack of logical clarity).

Just my opinion, as I said. Disagreements welcome.

On Fri, 6 Sep 2019 at 08:59, Andrea Giammarchi 
wrote:

> The purpose is to address what chaining lacks, in terms of "stopping" at
> some point whenever it's available or not.
>
> Take this example:
>
> ```js
> // the current chaining operator
> const result = nmsp.some.payload()?.result ?? nmsp.some.payload();
>
> // the mouse operator
> const result = nmsp.some.payload() ```
>
> Keeping it semantic, the mouse operator is "a trap" for the chain that
> makes reading possible expensive parts of the chain easier. An utility to
> obtain the same code would look something like the following:
>
> ```js
> // the mouse utility
> const mouse = trap => {
>   // a way to self clean right after, as it is for RegExp.$* values
>   // which is something impossible to obtain with regular syntax
>   Promise.resolve(mouse.trap = trap).then(() => delete mouse.trap);
>   return trap;
> };
>
> // the previous example
> const result = mouse(nmsp.some.payload())?.result ?? mouse.trap;
> ```
>
> Since there is no easy way to syntactically obtain the same with the
> current `?` and `??` without repeating all steps in the right side of the
> `??`, I've thought this "mouse operator" would play a role to actually
> avoid bugs easily introduced by repeating calls on the right hand side of
> the `??` either via getters or expensive operations.
>
> It is also possible to keep going on a chain or eventually provide
> feedbacks of what went wrong:
>
> ```js
> const name = await some.query(id) if (typeof name !== 'string')
>   throw name;
> ```
>
> As summary, considering how semantic it's the operator in both visual and
> practical meanings, and considering it's not possible to achieve the same
> result through `??`, I wish it would be considered as complementary help
> for the recently introduced `?.` and `??` syntax.
>
> So thanks in advance for possible consideration.
>
> Regards
>
>
> On Fri, Sep 6, 2019 at 9:14 AM Naveen Chawla 
> wrote:
>
>> I think introducing this operator encourages bad logic design like
>> "instanceof", isArray etc. These are unreadable disambiguation factors in
>> that they don't inform about which part the expression is going to the next
>> stage in the process. Also it leads to "type branching", which tends
>> towards more convoluted logical flow. These things, in my mind, would lead
>> to more bugs. Hence I would tend to be against introducing it, especially
>> in light of other proposals that I find more useful that haven't been taken
>> even to discussion.
>>
>> On Fri, 6 Sep 2019, 07:58 Claude Pache,  wrote:
>>
>>>
>>>
>>> Le 5 sept. 2019 à 23:39, Andrea Giammarchi 
>>> a écrit :
>>>
>>> This is basically a solution to a common problem we have these days,
>>> where modules published in the wild might have a `default` property, to
>>> support ESM logic, or not.
>>>
>>> ```js
>>> // current optional chaining logic
>>> const imported = exported?.default ?? exported;
>>>
>>> // my "mice operator" proposal
>>> const imported = exported>> ```
>>>
>>>
>>>
>>> The semantics of the `?.` in `exported?.default` is not to check whether
>>> the `default` property exists, but whether `exported` evaluates to
>>> undefined or null. If the `default` property is absent, `exported.default`
>>> has always evaluated to `undefined`, and there is no need to optional
>>> chaining operator. So that I guess you actually meant:
>>>
>>> ``js
>>> const imported = exported.default ?? exported;
>>> ```
>>>
>>>
>>> —Claude
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>

Re: Optional chaining syntax but with the "mice" operator ?

[Felipe Nascimento de Moura]

Doesn't that bring risks to breaking the web?

You seen, many, MANY servers running php have the "shot-tags" feature
enabled, in which pages with  will be interpreted.
In this case, any html page with embedded scripts using this operator, or
event .js files when the server is configured to also run php in them, will
break.

Or am I missing something here?

[ ]s

*--*

*Felipe N. Moura*
Web Developer, Google Developer Expert
, Founder of
BrazilJS  and Nasc .

Website:  http://felipenmoura.com / http://nasc.io/
Twitter:@felipenmoura 
Facebook: http://fb.com/felipenmoura
LinkedIn: http://goo.gl/qGmq
-
*Changing  the  world*  is the least I expect from  myself!


On Fri, Sep 6, 2019 at 4:59 AM Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> The purpose is to address what chaining lacks, in terms of "stopping" at
> some point whenever it's available or not.
>
> Take this example:
>
> ```js
> // the current chaining operator
> const result = nmsp.some.payload()?.result ?? nmsp.some.payload();
>
> // the mouse operator
> const result = nmsp.some.payload() ```
>
> Keeping it semantic, the mouse operator is "a trap" for the chain that
> makes reading possible expensive parts of the chain easier. An utility to
> obtain the same code would look something like the following:
>
> ```js
> // the mouse utility
> const mouse = trap => {
>   // a way to self clean right after, as it is for RegExp.$* values
>   // which is something impossible to obtain with regular syntax
>   Promise.resolve(mouse.trap = trap).then(() => delete mouse.trap);
>   return trap;
> };
>
> // the previous example
> const result = mouse(nmsp.some.payload())?.result ?? mouse.trap;
> ```
>
> Since there is no easy way to syntactically obtain the same with the
> current `?` and `??` without repeating all steps in the right side of the
> `??`, I've thought this "mouse operator" would play a role to actually
> avoid bugs easily introduced by repeating calls on the right hand side of
> the `??` either via getters or expensive operations.
>
> It is also possible to keep going on a chain or eventually provide
> feedbacks of what went wrong:
>
> ```js
> const name = await some.query(id) if (typeof name !== 'string')
>   throw name;
> ```
>
> As summary, considering how semantic it's the operator in both visual and
> practical meanings, and considering it's not possible to achieve the same
> result through `??`, I wish it would be considered as complementary help
> for the recently introduced `?.` and `??` syntax.
>
> So thanks in advance for possible consideration.
>
> Regards
>
>
> On Fri, Sep 6, 2019 at 9:14 AM Naveen Chawla 
> wrote:
>
>> I think introducing this operator encourages bad logic design like
>> "instanceof", isArray etc. These are unreadable disambiguation factors in
>> that they don't inform about which part the expression is going to the next
>> stage in the process. Also it leads to "type branching", which tends
>> towards more convoluted logical flow. These things, in my mind, would lead
>> to more bugs. Hence I would tend to be against introducing it, especially
>> in light of other proposals that I find more useful that haven't been taken
>> even to discussion.
>>
>> On Fri, 6 Sep 2019, 07:58 Claude Pache,  wrote:
>>
>>>
>>>
>>> Le 5 sept. 2019 à 23:39, Andrea Giammarchi 
>>> a écrit :
>>>
>>> This is basically a solution to a common problem we have these days,
>>> where modules published in the wild might have a `default` property, to
>>> support ESM logic, or not.
>>>
>>> ```js
>>> // current optional chaining logic
>>> const imported = exported?.default ?? exported;
>>>
>>> // my "mice operator" proposal
>>> const imported = exported>> ```
>>>
>>>
>>>
>>> The semantics of the `?.` in `exported?.default` is not to check whether
>>> the `default` property exists, but whether `exported` evaluates to
>>> undefined or null. If the `default` property is absent, `exported.default`
>>> has always evaluated to `undefined`, and there is no need to optional
>>> chaining operator. So that I guess you actually meant:
>>>
>>> ``js
>>> const imported = exported.default ?? exported;
>>> ```
>>>
>>>
>>> —Claude
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Refer to actual value : keyword "itself"

[Cyril Auburtin]

also optional-chaining will help
```js
return {
...state,
child: {
...state?.child,
subchild: {
...state?.child?.subchild,
property: (state?.child?.subchild?.property ?? 0) + 1
}
}
}
```

@Herby yes that's interesting, works in any order actually `const {child,
child: {subchild}} = state;`

On Fri, Sep 6, 2019 at 11:23 AM Herby Vojčík  wrote:

> On 6. 9. 2019 10:34, Cyril Auburtin wrote:
> > You could currently do
> > ```js
> > object.child.property /= 5
> > ```
> >
> > with destructuring:
> > ```js
> > const {child: {subchild}, child} = state;
>
> Wow, I didn't know I can do that. Nice.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Refer to actual value : keyword "itself"

[Herby Vojčík]

On 6. 9. 2019 10:34, Cyril Auburtin wrote:

You could currently do
```js
object.child.property /= 5
```

with destructuring:
```js
const {child: {subchild}, child} = state;


Wow, I didn't know I can do that. Nice.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Refer to actual value : keyword "itself"

[Imeian .]

Yes of course I could use the /= operator in this simple example, but not
in more complex operations.

About itself in a property, it's correct : I mean itself to refer to the
actual value, the value being from a variable or an object property doesn't
matter. itself would not be a this equivalent, so whenever itself is used
it refers to the actual value we are assigning

Le ven. 6 sept. 2019 à 10:34, Cyril Auburtin  a
écrit :

> You could currently do
> ```js
> object.child.property /= 5
> ```
>
> with destructuring:
> ```js
> const {child: {subchild}, child} = state;
>
> return {
>   ...state,
>   child: {
> ...child,
> subchild: {
>   ...subchild,
>   property: subchild.property + 1
> }
>   }
> }
> ```
>
> or do-expressions:
> ```js
> return {
>   ...state,
>   child: do {
> const {child} = state;
> return {
>   ...child,
>   subchild: do {
> const {subchild} = child;
> return {
>   ...subchild,
>   property: subchild.property + 1
> };
>   }
> };
>   }
> }
> ```
>
> note: your `property: itself + 1` looks incorrect, since you probably mean
> to increment the `property` property
>
> On Fri, Sep 6, 2019 at 9:36 AM Imeian .  wrote:
>
>> When we need to change a value using the old value :
>>
>> variable = itself + 5 // instead of
>> variable = variable + 5
>>
>> object.child.property = itself / 5 // instead of
>> object.child.property = object.child.property / 5
>>
>> Changing a value in nested objects is a pain, like Redux states for eg.
>>
>> return {
>> ...state,
>> child: {
>> ...state.child,
>> subchild: {
>> ...state.child.subchild,
>> property: state.child.subchild.property + 1
>> }
>> }
>> }
>>
>> would then be
>>
>> return {
>> ...state,
>> child: {
>> ...itself,
>> subchild: {
>> ...itself,
>> property: itself + 1
>> }
>> }
>> }
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Refer to actual value : keyword "itself"

[Cyril Auburtin]

Oops I forgot do-expression don't use `return`, so something, a bit ugly,
like:
```js
return {
  ...state,
  child: do {
const {child} = state;
({
  ...child,
  subchild: do {
const {subchild} = child;
({
  ...subchild,
  property: subchild.property + 1
});
  }
});
  }
}
```

On Fri, Sep 6, 2019 at 10:34 AM Cyril Auburtin 
wrote:

> You could currently do
> ```js
> object.child.property /= 5
> ```
>
> with destructuring:
> ```js
> const {child: {subchild}, child} = state;
>
> return {
>   ...state,
>   child: {
> ...child,
> subchild: {
>   ...subchild,
>   property: subchild.property + 1
> }
>   }
> }
> ```
>
> or do-expressions:
> ```js
> return {
>   ...state,
>   child: do {
> const {child} = state;
> return {
>   ...child,
>   subchild: do {
> const {subchild} = child;
> return {
>   ...subchild,
>   property: subchild.property + 1
> };
>   }
> };
>   }
> }
> ```
>
> note: your `property: itself + 1` looks incorrect, since you probably mean
> to increment the `property` property
>
> On Fri, Sep 6, 2019 at 9:36 AM Imeian .  wrote:
>
>> When we need to change a value using the old value :
>>
>> variable = itself + 5 // instead of
>> variable = variable + 5
>>
>> object.child.property = itself / 5 // instead of
>> object.child.property = object.child.property / 5
>>
>> Changing a value in nested objects is a pain, like Redux states for eg.
>>
>> return {
>> ...state,
>> child: {
>> ...state.child,
>> subchild: {
>> ...state.child.subchild,
>> property: state.child.subchild.property + 1
>> }
>> }
>> }
>>
>> would then be
>>
>> return {
>> ...state,
>> child: {
>> ...itself,
>> subchild: {
>> ...itself,
>> property: itself + 1
>> }
>> }
>> }
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Proposal] Refer to actual value : keyword "itself"

[Cyril Auburtin]

You could currently do
```js
object.child.property /= 5
```

with destructuring:
```js
const {child: {subchild}, child} = state;

return {
  ...state,
  child: {
...child,
subchild: {
  ...subchild,
  property: subchild.property + 1
}
  }
}
```

or do-expressions:
```js
return {
  ...state,
  child: do {
const {child} = state;
return {
  ...child,
  subchild: do {
const {subchild} = child;
return {
  ...subchild,
  property: subchild.property + 1
};
  }
};
  }
}
```

note: your `property: itself + 1` looks incorrect, since you probably mean
to increment the `property` property

On Fri, Sep 6, 2019 at 9:36 AM Imeian .  wrote:

> When we need to change a value using the old value :
>
> variable = itself + 5 // instead of
> variable = variable + 5
>
> object.child.property = itself / 5 // instead of
> object.child.property = object.child.property / 5
>
> Changing a value in nested objects is a pain, like Redux states for eg.
>
> return {
> ...state,
> child: {
> ...state.child,
> subchild: {
> ...state.child.subchild,
> property: state.child.subchild.property + 1
> }
> }
> }
>
> would then be
>
> return {
> ...state,
> child: {
> ...itself,
> subchild: {
> ...itself,
> property: itself + 1
> }
> }
> }
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Andrea Giammarchi]

The purpose is to address what chaining lacks, in terms of "stopping" at
some point whenever it's available or not.

Take this example:

```js
// the current chaining operator
const result = nmsp.some.payload()?.result ?? nmsp.some.payload();

// the mouse operator
const result = nmsp.some.payload() {
  // a way to self clean right after, as it is for RegExp.$* values
  // which is something impossible to obtain with regular syntax
  Promise.resolve(mouse.trap = trap).then(() => delete mouse.trap);
  return trap;
};

// the previous example
const result = mouse(nmsp.some.payload())?.result ?? mouse.trap;
```

Since there is no easy way to syntactically obtain the same with the
current `?` and `??` without repeating all steps in the right side of the
`??`, I've thought this "mouse operator" would play a role to actually
avoid bugs easily introduced by repeating calls on the right hand side of
the `??` either via getters or expensive operations.

It is also possible to keep going on a chain or eventually provide
feedbacks of what went wrong:

```js
const name = await some.query(id) wrote:

> I think introducing this operator encourages bad logic design like
> "instanceof", isArray etc. These are unreadable disambiguation factors in
> that they don't inform about which part the expression is going to the next
> stage in the process. Also it leads to "type branching", which tends
> towards more convoluted logical flow. These things, in my mind, would lead
> to more bugs. Hence I would tend to be against introducing it, especially
> in light of other proposals that I find more useful that haven't been taken
> even to discussion.
>
> On Fri, 6 Sep 2019, 07:58 Claude Pache,  wrote:
>
>>
>>
>> Le 5 sept. 2019 à 23:39, Andrea Giammarchi 
>> a écrit :
>>
>> This is basically a solution to a common problem we have these days,
>> where modules published in the wild might have a `default` property, to
>> support ESM logic, or not.
>>
>> ```js
>> // current optional chaining logic
>> const imported = exported?.default ?? exported;
>>
>> // my "mice operator" proposal
>> const imported = exported> ```
>>
>>
>>
>> The semantics of the `?.` in `exported?.default` is not to check whether
>> the `default` property exists, but whether `exported` evaluates to
>> undefined or null. If the `default` property is absent, `exported.default`
>> has always evaluated to `undefined`, and there is no need to optional
>> chaining operator. So that I guess you actually meant:
>>
>> ``js
>> const imported = exported.default ?? exported;
>> ```
>>
>>
>> —Claude
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[Proposal] Refer to actual value : keyword "itself"

[Imeian .]

When we need to change a value using the old value :

variable = itself + 5 // instead of
variable = variable + 5

object.child.property = itself / 5 // instead of
object.child.property = object.child.property / 5

Changing a value in nested objects is a pain, like Redux states for eg.

return {
...state,
child: {
...state.child,
subchild: {
...state.child.subchild,
property: state.child.subchild.property + 1
}
}
}

would then be

return {
...state,
child: {
...itself,
subchild: {
...itself,
property: itself + 1
}
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Naveen Chawla]

I think introducing this operator encourages bad logic design like
"instanceof", isArray etc. These are unreadable disambiguation factors in
that they don't inform about which part the expression is going to the next
stage in the process. Also it leads to "type branching", which tends
towards more convoluted logical flow. These things, in my mind, would lead
to more bugs. Hence I would tend to be against introducing it, especially
in light of other proposals that I find more useful that haven't been taken
even to discussion.

On Fri, 6 Sep 2019, 07:58 Claude Pache,  wrote:

>
>
> Le 5 sept. 2019 à 23:39, Andrea Giammarchi 
> a écrit :
>
> This is basically a solution to a common problem we have these days, where
> modules published in the wild might have a `default` property, to support
> ESM logic, or not.
>
> ```js
> // current optional chaining logic
> const imported = exported?.default ?? exported;
>
> // my "mice operator" proposal
> const imported = exported ```
>
>
>
> The semantics of the `?.` in `exported?.default` is not to check whether
> the `default` property exists, but whether `exported` evaluates to
> undefined or null. If the `default` property is absent, `exported.default`
> has always evaluated to `undefined`, and there is no need to optional
> chaining operator. So that I guess you actually meant:
>
> ``js
> const imported = exported.default ?? exported;
> ```
>
>
> —Claude
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Claude Pache]

> Le 5 sept. 2019 à 23:39, Andrea Giammarchi  a 
> écrit :
> 
> This is basically a solution to a common problem we have these days, where 
> modules published in the wild might have a `default` property, to support ESM 
> logic, or not.
> 
> ```js
> // current optional chaining logic
> const imported = exported?.default ?? exported;
> 
> // my "mice operator" proposal
> const imported = exported ```
> 


The semantics of the `?.` in `exported?.default` is not to check whether the 
`default` property exists, but whether `exported` evaluates to undefined or 
null. If the `default` property is absent, `exported.default` has always 
evaluated to `undefined`, and there is no need to optional chaining operator. 
So that I guess you actually meant:

``js
const imported = exported.default ?? exported;
```


—Claude___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Optional chaining syntax but with the "mice" operator ?

[Andrea Giammarchi]

As someone noticed already, the operator should be called eventually
"mouse" operator, as mice is plural and was a misunderstand of mine 

On Fri, Sep 6, 2019, 00:54 Andrea Giammarchi 
wrote:

> Since somebody asked me already elsewhere about the expected precedence of
> the operator, this would be my answer:
>
> ```js
> const result = await dbQuery(data) ```
>
> would be the equivalent of
>
> ```js
> let result = await dbQuery(data);
> if (result != null && result.rows != null)
>   result = result.rows;
> ```
>
> or to better answer about precedence:
>
> ```js
> const result = (await dbQuery(data)) ```
>
> I hope this adds some extra context to this proposal.
>
>
> On Fri, Sep 6, 2019 at 12:28 AM Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> absolutely, I'm working with PostgreSQL these days and indeed for any
>> promise/awaited result this pattern looks like a win, and while it's
>> targeting a limitation of the chaining one, it can be used in various other
>> cases where knowing the initial result is more important than just falling
>> back to "_dunnoWhatHappenedThere_"
>>
>> On Fri, Sep 6, 2019 at 12:24 AM Michael Luder-Rosefield <
>> rosyatran...@gmail.com> wrote:
>>
>>> Another pattern it could be useful in is with, say, nosql dbs where
>>> something might be an object or id reference:
>>>
>>> ```
>>> const fooId = foo>> ```
>>>
>>> On Thu, 5 Sep 2019, 23:03 Andrea Giammarchi, <
>>> andrea.giammar...@gmail.com> wrote:
>>>
 Another use case that I believe will be common is the following one:

 ```js
 // current state of the art
 const result = dbQuery(data)?.rows ?? 'did it just failed or what?';

 // VS the "mice operator"
 const result = dbQuery(data)>>>
 // if it was rows
 if (Array.isArray(result))
   console.log(result);
 else if (result instanceof Error)
   console.error(result.message);
 else
   console.warn(`unexpected result: ${result}`);
 ```

 Ideally, the "mice" should grant chaining up to its latest presence,
 but I wouldn't know right now how to reference to it ...

 ```js
 // if no ?? is needed, this might work
 const result = dbQuery(data)>>>
 // if ?? is needed, no idea how to back-reference the latest
 successfull "mice" result
 ```




 On Thu, Sep 5, 2019 at 11:44 PM Tab Atkins Jr. 
 wrote:

> On Thu, Sep 5, 2019 at 2:39 PM Andrea Giammarchi
>  wrote:
> >
> > This is basically a solution to a common problem we have these days,
> where modules published in the wild might have a `default` property, to
> support ESM logic, or not.
> >
> > ```js
> > // current optional chaining logic
> > const imported = exported?.default ?? exported;
> >
> > // my "mice operator" proposal
> > const imported = exported > ```
> >
> > Semantically speaking, not only ` also points at its previous value in case the chaining didn't work.
> >
> > Beside the basic example, the "mice operator" might save CPU cycles
> when it comes to involving more complex expressions, i.e.
> >
> > ```js
> > // current "solution"
> > const thing = require('thing')?.default ?? require('thing');
> >
> > // mice operator
> > const thing = require('thing') > ```
> >
> > This is also easily tranpilable, so kinda a no-brainer for modern
> dev tools to bring in.
> >
> > TL;DR specially for cases where an accessed property should fallback
> to its source, this operator might save both typing and CPU time whenever
> it's needed.
>
> I find it a rather curious pattern, that I'd never seen before! Is it
> used in anything besides this ESM-compat thing you're talking about?
>
> (Saving CPU cycles is not a convincing argument; it's trivial to write
> such a line over two declarations and avoid any expensive
> recomputations.)
>
> ~TJ
>
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

>>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss