guest271314 at gmail.com (2019-06-08T00:37:18.358Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather (if reading the below linked answer correctly) the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal is technically already possible using existing JavaScript features (default values; default parameters; ```...``` syntax
> ```fun(a, b, ...c)```: This construct doesn't actually have a name in the spec (http://www.ecma-international.org/ecma-262/6.0/#sec-left-hand-side-expressions). But it works very similar as spread elements do: It expands an iterable into the list of arguments. It would be equivalent to ```func.apply(null, [a, b].concat(c))```.
(https://stackoverflow.com/a/37152508); generator function; ```Object.assign()```; computed property name; destructuring assignment; et al.).guest271314 at gmail.com (2019-06-08T00:32:31.946Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather (if reading the below linked answer correctly) the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal is technically already possible using existing JavaScript features (default values; default parameters; ```...``` syntax; generator function; ```Object.assign()```; computed property name; destructuring assignment; et al.).guest271314 at gmail.com (2019-06-07T22:40:26.275Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather (if reading the below linked answer correctly) the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal is technically already possible using existing JavaScript features (default values; default parameters).guest271314 at gmail.com (2019-06-07T22:33:22.260Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather (if reading the below linked answer correctly) the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal is technically already possible using existing JavaScript features (i.e., default parameters).guest271314 at gmail.com (2019-06-07T22:30:26.781Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather (if reading the below linked answer correctly) the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal is technically already possible using existing JavaScript features (e.g. "dynamic" default parameters).guest271314 at gmail.com (2019-06-07T22:30:14.301Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather (if reading the linked answer correctly) the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal is technically already possible using existing JavaScript features (e.g. "dynamic" default parameters).guest271314 at gmail.com (2019-06-07T22:29:31.281Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal is technically already possible using existing JavaScript features (e.g. "dynamic" default parameters).guest271314 at gmail.com (2019-06-07T22:26:59.960Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal is technically already possible using existing JavaScript features.guest271314 at gmail.com (2019-06-07T22:25:47.024Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value (Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>).
The proposal appears to be already possible using existing JavaScript features.guest271314 at gmail.com (2019-06-07T22:24:48.725Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of "appending" the extra arguments.
From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>.
The proposal appears to be already possible using existing JavaScript features.guest271314 at gmail.com (2019-06-07T22:24:15.346Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while (true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of appending the extra arguments.
From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>.
The proposal appears to be already possible using existing JavaScript features.guest271314 at gmail.com (2019-06-07T22:23:58.479Z)
> its counter-intuitive in javascript that appending extra args to a
> function re-arranges arg-positioning and invalidates existing calls.
Appending extra arguments to a function is not an issue. A generator now be
can be passed to a function
```function* gen(n = 0) { while(true) { yield ++n } }```
```match(...gen())```
where the author should reasonably expect (or will discover) that subsequent arguments could affect
previous arguments; which could, in general, be the purpose of appending the extra arguments.
From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value Does any JavaScript specification define the order of function execution where the
arguments to the function are a nested array of function calls? #1397
<https://github.com/tc39/ecma262/issues/1397>.
The proposal appears to be already possible using existing JavaScript features.guest271314 at gmail.com (2019-06-07T22:22:54.374Z)
> its counter-intuitive in javascript that appending extra args to a > function re-arranges arg-positioning and invalidates existing calls. Appending extra arguments to a function is not an issue. A generator now be can be passed to a function ```match(...gen())``` where the author should reasonably expect (or will discover) that subsequent arguments could affect previous arguments; which could, in general, be the purpose of appending the extra arguments. From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value Does any JavaScript specification define the order of function execution where the arguments to the function are a nested array of function calls? #1397 <https://github.com/tc39/ecma262/issues/1397>. The proposal appears to be already possible using existing JavaScript features.
guest271314 at gmail.com (2019-06-07T22:21:21.996Z)
> its counter-intuitive in javascript that appending extra args to a > function re-arranges arg-positioning and invalidates existing calls. Appending extra arguments to a function is not an issue. A generator now be can be passed to a function ```match(...gen())``` where the author should expect that subsequent arguments could affect previous arguments; which could, in general, be the purpose of appending the extra arguments. From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value Does any JavaScript specification define the order of function execution where the arguments to the function are a nested array of function calls? #1397 <https://github.com/tc39/ecma262/issues/1397>. The proposal is already be possible using existing JavaScript features.
> > its counter-intuitive in javascript that appending extra args to a > function re-arranges arg-positioning and invalidates existing calls. Appending extra arguments to a function is not an issue. A generator now be can be passed to a function ```match(...gen())``` where the author should expect that subsequent arguments could affect previous arguments; which could, in general, be the purpose of appending the extra arguments. >From what have been able to gather, the arguments to a function are processed from right to left; from the inner-most nested value Does any JavaScript specification define the order of function execution where the arguments to the function are a nested array of function calls? #1397 <https://github.com/tc39/ecma262/issues/1397>. The proposal appears to already be possible using existing JavaScript features. On Fri, Jun 7, 2019 at 5:11 PM kai zhu <kaizhu256 at gmail.com> wrote: > it matters when you have to debug/inherit *other* people's code (and clean > up their mess). i wouldn't enjoy debugging unfamiliar-code that used this > feature (admittedly, its my subjective opinion). > > the maintainability argument stands -- its counter-intuitive in javascript > that appending extra args to a function re-arranges arg-positioning and > invalidates existing calls. > > debuggability is subjective i agree. > > p.s. - in general, i don't see what *real* painpoint rest-operator > actually address, that couldn't be solved with `arguments`. > variable-arg-length functions are not javascripty -- they frequently > require extra ux-workflow transformations like Function.p.apply or > Array.p.flatmap to the arguments being passed. > > > On Fri, Jun 7, 2019 at 10:07 AM Isiah Meadows <isiahmeadows at gmail.com> > wrote: > >> For your maintainability argument: adding extra arguments to those >> functions is something I almost never do. And you'd have the same >> exact issue with final rest parameters, just in a different position >> (in the middle as opposed to in the end). >> >> For debuggability, I don't see how it'd be a major issue unless you >> already have an excessive number of *positional* parameters. In my >> experience, the debuggability issues arise approximately when there's >> just too many positional parameters, and factoring out the rest >> parameter to an array doesn't really help this situation much. (That's >> when object destructuring comes in handy.) >> >> So not convinced either is any different than what it's like today. >> >> Also, you aren't obligated to use a feature just because it exists - I >> hardly ever use proxies, for instance, and I rarely need maps beyond >> what objects give me, so I don't normally use them unless I need to >> have reference types or mixed types as keys. >> >> ----- >> >> Isiah Meadows >> contact at isiahmeadows.com >> www.isiahmeadows.com >> >> On Thu, Jun 6, 2019 at 2:22 PM kai zhu <kaizhu256 at gmail.com> wrote: >> > >> > -1 for maintainability and debuggability >> > >> > 1. maintainability >> > if you want to extend the function with additional args, >> > then you'll have to retroactively modify all existing calls to avoid >> off-by-one argcount: >> > >> > ```js >> > // if extending function with additional args >> > function pad(targetLength, ...opts, data) -> >> > function pad(targetLength, ...opts, data, meta) >> > >> > // then must retroactively append null/undefined to all existing calls >> > pad(1, opt1, opt2, "data") -> >> > pad(1, opt1, opt2, "data", null) >> > ``` >> > >> > >> > >> > 2. debuggability >> > when debugging, it takes longer for human to figure out which arg is >> what: >> > >> > ```js >> > // function pad(targetLength, ...opts, data) >> > pad(aa, bb, cc, dd); >> > pad(aa, bb, cc, dd, ee); >> > >> > // vs >> > >> > // function pad(targetLength, opts, data) >> > pad(aa, [bb, cc], dd); >> > pad(aa, [bb, cc, dd], ee); >> > ``` >> > >> > >> > >> > On Thu, Jun 6, 2019 at 11:54 AM Ethan Resnick <ethan.resnick at gmail.com> >> wrote: >> >> >> >> Long-time mostly-lurker on here. I deeply appreciate all the hard work >> that folks here put into JS. >> >> >> >> I've run into a couple cases now where it'd be convenient to use a >> rest operator at the beginning or middle of an array destructuring, as in: >> >> >> >> ``` >> >> const [...xs, y] = someArray; >> >> ``` >> >> >> >> Or, similarly, in function signatures: >> >> >> >> ``` >> >> function(...xs, y) { } >> >> ``` >> >> >> >> The semantics would be simple: exhaust the iterable to create the >> array of `xs`, like a standard rest operator would do, but then slice off >> the last item and put it in `y`. >> >> >> >> For example, I was working with some variable argument functions that, >> in FP style, always take their data last. So I had a function like this: >> >> >> >> ``` >> >> function match(...matchersAndData) { >> >> const matchers = matchersAndData.slice(0, -1); >> >> const data = matchersAndData[matchersAndData.length - 1]; >> >> // do matching against data >> >> } >> >> ``` >> >> >> >> Under this proposal, the above could be rewritten: >> >> >> >> ``` >> >> function reduce(...matchers, data) { /* ... */ } >> >> ``` >> >> >> >> Another example: a function `pad`, which takes a target length and a >> string to pad, with an optional padding character argument in between: >> >> >> >> ``` >> >> function pad(targetLength, ...paddingCharAndOrData) { >> >> const [paddingChar = " "] = paddingCharAndOrData.slice(0, -1); >> >> const data = paddingCharAndOrData[paddingCharAndOrData.length - 1]; >> >> >> >> // pad data with paddingChar to targetLength; >> >> } >> >> ``` >> >> >> >> With this proposal, that could be rewritten: >> >> >> >> ``` >> >> function pad(targetLength, ...opts, data) { >> >> const [paddingChar = " "] = opts; >> >> // pad data with paddingChar to targetLength; >> >> } >> >> ``` >> >> >> >> I'm curious if this has been considered before, and what people think >> of the idea. >> >> >> >> Obviously, if `...a` appeared at the beginning or middle of a list, >> there would have to be a fixed number of items following it, so a >> subsequent rest operator in the same list would not be allowed. >> >> >> >> Thanks >> >> >> >> _______________________________________________ >> >> es-discuss mailing list >> >> es-discuss at mozilla.org >> >> https://mail.mozilla.org/listinfo/es-discuss >> > >> > _______________________________________________ >> > es-discuss mailing list >> > es-discuss at mozilla.org >> > https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190607/64f698e8/attachment-0001.html>