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
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 {
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
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
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 =
> 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
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
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
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,
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
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
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
> 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
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
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` (
`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: {
>
> 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
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:
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
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
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:
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:
> -
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
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
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
*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.
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
27 matches
Mail list logo
