Herby, for those like myself who aren’t familiar with “classical
let-in,” could you explain more about the objective? It’s not clear to
me from the brief example what advantages this would provide.
Basically just readability / concise code.
The case I wanted to come with is, with more code looking
expression-based as compared to statement / curled-braced-body based, to
which I used the example of arrow functions and their
right-associativity, that is:
store => next => action => /impl/,
one feel the need to avoid simple cases of breaking it like
store => next => {
const wrappedNext = wrapper(next);
return action => /impl using wrappedNext/
}
which break the process of scanning the => sequence.
It may be useful in other cases, similarly as, for example, the
aformenetioned arrow functions proliferated (and in all due respect, it
wasn't only because of their this-handling, b/c most of them do not
use this at all; but because they are more convenient to write / easier
to read).
store => next => let wrappedNext=wrapper(next), in action => /impl/
b/c "let ..., in ..." stays in expression context.
Darien Valentine wrote on 24. 8. 2018 10:41:
> Herby, for those like myself who aren’t familiar with “classical
> let-in,” could you explain more about the objective? It’s not clear to
> me from the brief example what advantages this would provide.
Basically just readability / concise code.
The case I wanted to come with is, with more code looking
expression-based as compared to statement / curled-braced-body based, to
which I used the example of arrow functions and their
right-associativity, that is:
store => next => action => /*impl*/,
one feel the need to avoid simple cases of breaking it like
store => next => {
const wrappedNext = wrapper(next);
return action => /*impl using wrappedNext*/
}
which break the process of scanning the => sequence.
It may be useful in other cases, similarly as, for example, the
aformenetioned arrow functions proliferated (and in all due respect, it
wasn't _only_ because of their this-handling, b/c most of them do not
use this at all; but because they are more convenient to write / easier
to read).
But otherwise
let foo=bar, baz=quux, in /*impl*/
would be basically just a syntactic sugar for
(() => {let foo=bar, baz=quux; return completionof /*impl*/}())
but would not necessarily optically break the
store => next => let wrappedNext=wrapper(next), in action => /*impl*/
b/c "let ..., in ..." stays in expression context.
Herby
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
Darien Valentine wrote on 24. 8. 2018 10:41:
Basically just readability / concise code.
The case I wanted to come with is, with more code looking expression-based as compared to statement / curled-braced-body based, to which I used the example of arrow functions and their right-associativity, that is:
store => next => action => /impl/,
one feel the need to avoid simple cases of breaking it like
store => next => { const wrappedNext = wrapper(next); return action => /impl using wrappedNext/ }
which break the process of scanning the => sequence.
It may be useful in other cases, similarly as, for example, the aformenetioned arrow functions proliferated (and in all due respect, it wasn't only because of their this-handling, b/c most of them do not use this at all; but because they are more convenient to write / easier to read).
But otherwise
let foo=bar, baz=quux, in /impl/
would be basically just a syntactic sugar for
(() => {let foo=bar, baz=quux; return completionof /impl/}())
but would not necessarily optically break the
store => next => let wrappedNext=wrapper(next), in action => /impl/
b/c "let ..., in ..." stays in expression context.
Darien Valentine wrote on 24. 8. 2018 10:41: > Herby, for those like myself who aren’t familiar with “classical > let-in,” could you explain more about the objective? It’s not clear to > me from the brief example what advantages this would provide. Basically just readability / concise code. The case I wanted to come with is, with more code looking expression-based as compared to statement / curled-braced-body based, to which I used the example of arrow functions and their right-associativity, that is: store => next => action => /*impl*/, one feel the need to avoid simple cases of breaking it like store => next => { const wrappedNext = wrapper(next); return action => /*impl using wrappedNext*/ } which break the process of scanning the => sequence. It may be useful in other cases, similarly as, for example, the aformenetioned arrow functions proliferated (and in all due respect, it wasn't _only_ because of their this-handling, b/c most of them do not use this at all; but because they are more convenient to write / easier to read). But otherwise let foo=bar, baz=quux, in /*impl*/ would be basically just a syntactic sugar for (() => {let foo=bar, baz=quux; return completionof /*impl*/}()) but would not necessarily optically break the store => next => let wrappedNext=wrapper(next), in action => /*impl*/ b/c "let ..., in ..." stays in expression context. Herby > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >