These are chat archives for jdubray/sam

20th
Oct 2016
Edward Mulraney
@edmulraney
Oct 20 2016 16:04
agreed
Fred Daoud
@foxdonut
Oct 20 2016 17:44
JavaScript fun: what is the result of ["10", "10", "10"].map(parseInt)? Should be [10, 10, 10], right? Wrong! It's [10, NaN, 2] :astonished: For bonus points, explain why.
Charles Rector
@chuckrector
Oct 20 2016 17:49
map passes multiple params to the mapping function
and parseInt takes a couple params too
so they will get confused
reminds me of event binding shenanigans i've seen in our infrastructure
where someone will create doSomething function with no params and then wire up foo.addEventListener('click', doSomething)
and it will work great until someone decides they want to add a param to doSomething so they can call it elsewhere (directly)
but then when it fires from the DOM, it gets an unexpected result as the param value -- the event
Fred Daoud
@foxdonut
Oct 20 2016 17:57
@chuckrector correct! more specifically, map passes the value and the index within the array; parseFloat accepts the value and the radix. So you get the result of [parseInt("10", 0), parseInt("10", 1), parseInt("10", 2)]. Further, parseInt(value, 0) defaults to parseInt(value, 10).
Charles Rector
@chuckrector
Oct 20 2016 17:58
so index becomes confused as the radix and so "10" at third index is offset 2... becoming binary!
so ["100", "100", "100"].map(parseInt) would be... [100, NaN, 4]
i suppose it is the "danger" of implicit args
i wonder if Typescript or Flow etc. helps with that sort of thing
Charles Rector
@chuckrector
Oct 20 2016 18:20
been having an interesting convo abt this in our corp slack
some ppl think it is a great demonstration of why "JS is terrible"
since some think the compiler should tell you when the params are incompatible
however, i think it is simply a matter of knowing your API, despite the fact that it may be "hostile" towards beginners
this would probably not be the common case but, the counter-point would be: you could still pass a function with exact same # params and types, but for which the usage/semantics are different, so you would still get conflation, probably producing unexpected output -- and the compiler would not be able to help you
Charles Rector
@chuckrector
Oct 20 2016 18:31
also for anyone wondering, you could do ["10", "10", "10"].map(Number) to get what you expect, since Number has only one param
in es6 i suppose you could also do ["10", "10", "10"].map(v=>~~v)... but that is not quite so beginner-friendly, heh
Fred Daoud
@foxdonut
Oct 20 2016 19:18
cool, @chuckrector . Also to be noted is that Number and parseIntdo not work the same. For example, they will give different results for "123abc" and also for "1.23". Another way is to make parseInt a unary function, with Ramda or Lodash for example, as in ["10", "10", "10"].map(R.unary(parseInt)).
Charles Rector
@chuckrector
Oct 20 2016 19:41
Ah, yes. Or perhaps the "obvious" yet more wordy ES5: ["10", "10", "10"].map(function(v) { return parseInt(v); })
Probably also explicitly passing 10 as a radix if you have some slightly funky inputs like "010"
Fred Daoud
@foxdonut
Oct 20 2016 20:32
@chuckrector agreed. if parseInt had fixed arity with required radix, then the radix would be the first argument. Further, if JS had automatic partial function application, then you could write ["10", "10", "10"].map(parseInt(10)); But, now I'm dreaming ;)
Charles Rector
@chuckrector
Oct 20 2016 20:33
we can build these dreams today! alas, they will not be standard for everyone
speaking of dreams, i had my first SAM-related dreams last night. in my dream, i was explaining the evolution of web development from wild-west to react to redux to SAM, and scribbling like mad on a chalkboard
Fred Daoud
@foxdonut
Oct 20 2016 20:50
:)