3 ms·
This has nothing to do with casts or defaults. Map passes multiple parameters and parseInt accepts multiple parameters. Being unaware of the functions you're us
by bastawhiz 7y ago
This has nothing to do with casts or defaults. Map passes multiple parameters and parseInt accepts multiple parameters. Being unaware of the functions you're using is the problem, not some sort of weird gotchas of the language. The code in the title makes multiple assumptions, and those assumptions all proved wrong.
- teraflop 7y agoI mean, I get that this particular example isn't really all that mysterious, but I think it's fair to say that "all parameters are optional and extra parameters are ignored" is a Javascript language gotcha.
- gameswithgo 7y agoA typed language would absolutely fail this at compile time.
- deleted 7y ago[deleted]
- zbentley 7y agoOnly because map's third provided argument exists. If map only supplied element and index to the callback, this would pass most type checkers I'm familiar with, and would remain just as confusing.
- tomxor 7y agoYes but with mandatory parameters the programmer would be aware parseInt had a radix in the first place if they had used it even once. That's one advantage of mandatory parameters, but there are of course disadvantages.
- horsawlarway 7y agoI'd argue basically everything about mandatory arguments is worse than having edgecases like this. Honestly, most languages STILL won't catch this, because the typical pattern is to use method overloading to provide multiple signatures if default arguments aren't supported. parseInt(in) parseInt(in, radix)
- ernst_klim 7y ago> I'd argue basically everything about mandatory arguments is worse than having edgecases like this. Any sane language having optional arguments is using keys for opt args. That's what common lisp and OCaml do. In OCaml you would write: let parse_int ?(radix = `Dec) string =... val parse_int : ?radix:[`Bin | `Oct | `Dec | `Hex] -> string -> int and call it like parse_int "42" - 42 parse_int ~radix:`Bin "111" - 7 List.mapi parse_int ["1"] - Static error: this expression has type `string -> int` but expected int -> 'a -> 'b
- happytoexplain 7y agoPrecisely - this is an API design failure, pure and simple. Not a problem with typing, optional arguments, etc.
- wutbrodo 7y agoIt's both. Silently accepting variadic arguments increases the odds of something like this happening. This case wouldn't have happened without it. Though as I said in another comment, best-effort parsing was a decision that arose out of the Web ecosystem and its one of the few things about Javascript's language design that can't br blamed on incompetence.
- zbentley 7y agoWhat does this have to do with best-effort parsing? "Variadic arguments" (really optional arguments with defaults/signature overloading, which is only arguably the same thing) existed long before JavaScript, and, indeed, the web. Optional arguments are also widely considered to be good/useful.
- bastawhiz 7y agoTyped languages can still have overloaded functions and optional parameters. You could easily encounter a similar issue in many typed languages.
- ajanuary 7y agoI would argue Javascript silently accepting more arguments than the function signature declares is kinda a gotcha. And that's what leads people to not realise map is passing extra arguments, because `list.map(a => f(a))` works.
- tomxor 7y agoI think the parent is talking about how C for instance does not have optional parameters (for better or worse), if this was the case for JS everyone who has ever used parseInt would be aware it takes a radix, but then again you also wouldn't be able to just plug it into map arbitrarily. Not saying one is better than the other, optional parameters can make for much less verbose code, I especially like parameter defaults introduced in ES6.