Ignoring arguments
Isiah Meadows
isiahmeadows at gmail.com
Thu Aug 11 20:28:47 UTC 2016
If you're talking about ignored function parameters in a declaration or
expression, much like `_` in several functional languages (like Haskell and
Scala), I could see value in that. I'd prefer an explicit token for that,
though, something like this:
```js
// ImmutableJS: convert map to list, only
// keeping values with integer keys
map
.filter((*, key) => typeof key === "number" && key % 1 === 0)
.toList()
```
On Thu, Aug 11, 2016, 12:51 Kris Siegel <krissiegel at gmail.com> wrote:
> ignoring/skipping argument in functions declarations (indeed the
>> invocations could be let apart)
>
>
> I am of the opinion that this is not a problem that needs to be solved at
> the language standardization level. The commas (or really any separator)
> for "skipping" a parameter looks like a mistake and is unintuitive (it's
> certainly not obvious to me what its intent is had I seen it without the
> context of this thread).
>
> This seems like a problem solved with better coding practices. I typically
> make required parameters first and then any optional ones in a separate,
> single parameter called options. Callbacks can be done with chaining /
> promises / I fmake them required / etc. Skipping callbacks usually isn't a
> good idea. We could talk all day about who's coding practice is better than
> who's but ultimately this problem should be solved by developing / adopting
> good coding practices.
>
> (Honestly I'm not a fan of the skipping in arrays either but considering
> it's an array I feel like it's at least a magnitude less confusing than
> doing it with function parameters)
>
> On Thu, Aug 11, 2016 at 4:00 AM, Cyril Auburtin <cyril.auburtin at gmail.com>
> wrote:
>
>> > Confused by this thread.
>>
>> It's quite simple though, _ would be a useless allocated variable, you
>> an't have more than 1, ...
>>
>> > What is the problem that this proposal is trying to solve?
>>
>> ignoring/skipping argument in functions declarations (indeed the
>> invocations could be let apart)
>>
>> > `Math.min(x,,y)`
>>
>> yes this kind of thing would give NaN, that's why you can `Math.min(x, ,
>> y)` write it with more spaces to avoid a typo mistake, indeed you could
>> still have like `Math.min(x, /*y (no longer used)*/ , z)` would. Like
>> said above, I realize the function invocations are sensible.
>>
>> So, it would be only for function declarations
>>
>> `div.addEventListener('click', () => { } )` says to skip all arguments,
>> and you've your callback scope is free of any additional vars
>>
>> `arr.forEach( x => { } )` says to only consider first argument, others
>> are skipped, and not in scope
>>
>> `Array.from({length: 19}, (, i) => i )` would be similar for the second
>> argument, similarly to array destructuring. It's not just for saving one
>> character, that's really not the matter, it's for standardizing this way,
>> because some people use `_`, some don't, ....
>>
>> 2016-08-10 16:27 GMT+02:00 Bob Myers <rtm at gol.com>:
>>
>>> Confused by this thread.
>>>
>>> > What if you could use a `.` as a wildcard?
>>>
>>> You can already use `_` or anything you want, as was already pointed out
>>> in early iterations of this idea.
>>>
>>> > it would avoid binding a usable identifier.
>>>
>>> What is the problem with that?
>>>
>>> What is the problem that this proposal is trying to solve? Any chance we
>>> could move on?
>>>
>>> Bob
>>>
>>>
>>>
>>> On Wed, Aug 10, 2016 at 7:48 PM, Alan Johnson <alan at breakrs.com> wrote:
>>>
>>>> What if you could use a `.` as a wildcard? I don’t think it would
>>>> conflict with existing syntax, and it would avoid binding a usable
>>>> identifier. It would be more obvious than nothing between the commas.
>>>>
>>>>
>>>> On Aug 8, 2016, at 06:33, Cyril Auburtin <cyril.auburtin at gmail.com>
>>>> wrote:
>>>>
>>>> Just bumping this up
>>>>
>>>> Calling `foo(1)` where foo is defined with 3 arguments, lets the 2
>>>> others undefined, this behavior is already a bit magic and similar to the
>>>> behavior of an array, so I still think foo(a,,b,,,c) should be like
>>>> foo(...[a,,b,,,c])
>>>>
>>>> Other example:
>>>> ```
>>>> var m=new Map([[1], [2,], [3,7]]) // Map {1 => undefined, 2 =>
>>>> undefined, 3 => 7} // here commas fantasies are allowed in arrays
>>>> m.set(3) // Map {1 => undefined, 2 => undefined, 3 => undefined} //
>>>> setting implicitely value as undefined
>>>> m.set(3, ) // not allowed, which should be m.set(...[3,])
>>>> ```
>>>>
>>>> and again, it would help for callbacks too, `something( ( , , thirdArg)
>>>> => {} )`
>>>>
>>>> I saw this https://jeffmo.github.io/es-trailing-function-commas/, it
>>>> seems like a sub-case
>>>>
>>>> 2016-05-29 23:07 GMT+02:00 Renki Ivanko <fatalis.erratum at gmail.com>:
>>>>
>>>>> One more similarity is that both function parameters and destructuring
>>>>> allow default values: (foo = 1) vs [foo = 1].
>>>>>
>>>>>
>>>>>
>>>>> On Sun, May 29, 2016 at 11:56 PM, Cyril Auburtin <
>>>>> cyril.auburtin at gmail.com> wrote:
>>>>>
>>>>>> Since functions arguments is an array under the hood, they could
>>>>>> 'more behave the same'
>>>>>>
>>>>>> Both function arguments and arrays accept spreading: *[1, 2,
>>>>>> ...args] * and *fn(1, 2, ...args)*
>>>>>>
>>>>>> a function definition like *(,i) => {}*, would be the equivalent of *var
>>>>>> [,i] = arguments*
>>>>>>
>>>>>> an invocation *fn(,,i)* would be the equivalent of *[,,i]*
>>>>>>
>>>>>> It's possible with *(...[,i]) => {}, (_,i)=>{} *like Renki said, but
>>>>>> slightly less simply
>>>>>>
>>>>>> Are there possible issues with that 'extension' of function syntax?
>>>>>>
>>>>>>
>>>>>> 2016-05-29 21:32 GMT+02:00 Renki Ivanko <fatalis.erratum at gmail.com>:
>>>>>>
>>>>>>> You could stop with "rare"; having to make up unused names is an
>>>>>>> obvious smell in comparison.
>>>>>>>
>>>>>>> ```js
>>>>>>> foo(UNUSED1, UNUSED2, x)
>>>>>>>
>>>>>>> foo(_, __, x)
>>>>>>>
>>>>>>> foo(,, x)
>>>>>>>
>>>>>>> foo(...[,, x])
>>>>>>> ```
>>>>>>>
>>>>>>> The latter is shorter and more explicit and would not be any more
>>>>>>> confusing if it became common.
>>>>>>>
>>>>>>>
>>>>>>> On Sun, May 29, 2016 at 8:46 PM, Bob Myers <rtm at gol.com> wrote:
>>>>>>>
>>>>>>>> Eliding array elements is not "similar" to eliding function formal
>>>>>>>> parameters. The latter is extremely rare, hardly readable, confusing,
>>>>>>>> bug-prone, and unnecessary because there is already a "standard way" which
>>>>>>>> is to use any old parameter name you want:
>>>>>>>>
>>>>>>>> ```js
>>>>>>>> function foo(UNUSED1, UNUSED2, x)
>>>>>>>> ````
>>>>>>>>
>>>>>>>> Most linters will not complain, or there are ways to shut them up
>>>>>>>> if they do.
>>>>>>>>
>>>>>>>> If you want to throw away an argument, just throw it away.
>>>>>>>>
>>>>>>>> ```js
>>>>>>>> function skipFirstParam(fn) { return ((first, ...args) =>
>>>>>>>> fn(...args)); }
>>>>>>>>
>>>>>>>> `[1,2,3,4].map(skipFirstParam(i => i));
>>>>>>>>
>>>>>>>> ```
>>>>>>>>
>>>>>>>> Or use Renki's solution.
>>>>>>>>
>>>>>>>> Bob
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sun, May 29, 2016 at 9:23 PM, Cyril Auburtin <
>>>>>>>> cyril.auburtin at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Similarly to:
>>>>>>>>>
>>>>>>>>> `var [,x,,y] = [1,2,3,4,5,6];`
>>>>>>>>>
>>>>>>>>> I think it could be interesting to let a field empty in function
>>>>>>>>> arguments
>>>>>>>>>
>>>>>>>>> `[1,2,3,4].map( (,i) => i )`, `Array.from({length:10}, (,i) => i )`
>>>>>>>>>
>>>>>>>>> `function test(a,,b) { }`
>>>>>>>>>
>>>>>>>>> (but that would alter the current parsing, that doesn't allow it)
>>>>>>>>>
>>>>>>>>> Currently I often use `_` as a way to mark ignored fields, but
>>>>>>>>> when there are more than 1 you need another identifier. A standard way
>>>>>>>>> would be interesting rather
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20160811/85b15150/attachment-0001.html>
More information about the es-discuss
mailing list