4 ms·

What would be a better spec for map() then? I think it would be to say that [...].mapBETTER(argFunk) calls its arg-function with just a single argument. The r

What would be a better spec for map() then? I think it would be to say that [...].mapBETTER(argFunk) calls its arg-function with just a single argument. The rest of the useful ("optional") arguments should be passed by binding "this" to the array of them. If bind() fails because the function was already bound, should throw an error. But this brings me to my pet-peeve: Why can't I map over Objects (other than Arrays)?

qayxc 3y ago
It doesn't have anything to do with the specs of map(). It's part of the core semantics of the language: function f() { } is equivalent to function f(a, b ,c) { } because under the hood the latter is simply function f() { let a = arguments[0] let b = arguments[1] let c = arguments[2] } Also no one stops you from simply extending the Array.prototype to your heart's content ¯\_(ツ)_/¯
- galaxyLogic 3y ago
  It has to do with the fact that map() passes 3 arguments to its argument function, right?
  - qayxc 3y ago
    Sure, if you want to look at it from that direction. Other languages, however, use a different default semantic for parameter passing and simply wouldn't allow using a function/lambda/delegate that doesn't explicitly take 3 arguments as well. JS interfaces are designed with the flexibility and semantics of the language in mind (no surprise there, really) and thus try to cover most use cases. If you don't need the index or the reference to the array in your function, ignore them (e.g. by using map(function(v) { ... })). Passing a function that actually supports more than one argument is by all accounts a layer 8 error and not a fault in the spec of map() IMO. You could just as well argue that it's bad for parseInt() to accept one or two arguments instead of explicitly requiring both. You'd have to try and convince me why one is perfectly fine while the other is not. You can of course argue that both specs are crap, that'd at least be consistent :)

qayxc 3y ago

It doesn't have anything to do with the specs of map(). It's part of the core semantics of the language: function f() { } is equivalent to function f(a, b ,c) { } because under the hood the latter is simply function f() { let a = arguments[0] let b = arguments[1] let c = arguments[2] } Also no one stops you from simply extending the Array.prototype to your heart's content ¯\_(ツ)_/¯

galaxyLogic 3y ago
It has to do with the fact that map() passes 3 arguments to its argument function, right?
- qayxc 3y ago
  Sure, if you want to look at it from that direction. Other languages, however, use a different default semantic for parameter passing and simply wouldn't allow using a function/lambda/delegate that doesn't explicitly take 3 arguments as well. JS interfaces are designed with the flexibility and semantics of the language in mind (no surprise there, really) and thus try to cover most use cases. If you don't need the index or the reference to the array in your function, ignore them (e.g. by using map(function(v) { ... })). Passing a function that actually supports more than one argument is by all accounts a layer 8 error and not a fault in the spec of map() IMO. You could just as well argue that it's bad for parseInt() to accept one or two arguments instead of explicitly requiring both. You'd have to try and convince me why one is perfectly fine while the other is not. You can of course argue that both specs are crap, that'd at least be consistent :)