3 ms·
That's not the problem. The problem is when a( <a list L> ) becomes a( l[0], l[1], l[2] ), which is bananas. you pass one object, you should stuff that into the
by jvanderbot 3y ago
That's not the problem. The problem is when a( <a list L> ) becomes a( l[0], l[1], l[2] ), which is bananas. you pass one object, you should stuff that into the first parameter.
- crazygringo 3y agoIt would prevent the bug, though. Passing the index and object for .map() can come in handy sometimes, so I understand the motivation for including it. But with named arguments, they could be passed as something like "_index:" and "_obj:", rather than getting slotted in as an arbitrary [1] and [2], where they can be misinterpreted as other parameters (like "radix").
- deleted 3y ago[deleted]
- deleted 3y ago[deleted]
- matt_kantor 3y agoI might be misunderstanding you, but if you're saying this is what's happening with `["1","2","3"].map(parseInt)`, that's not correct. The article describes the situation in detail, but `parseInt` is called three separate times (its first argument in each call is `"1"`, then `"2"`, then `"3"`, as you'd expect with any array-mapping operation). The weirdness arises because `.map` always passes more than one argument to the callback (and `parseInt` accepts more than one parameter). This happens even when the array has only a single element, it's just that the first call (`parseInt("1", 0, ["1"])`) happens to have the same return value as `parseInt("1")`, so you only notice the weirdness with the later elements.
- jvanderbot 3y agoI see! Thank you for clarifying.
- deleted 3y ago[deleted]