{"id":166,"date":"2011-02-24T15:27:19","date_gmt":"2011-02-24T23:27:19","guid":{"rendered":"http:\/\/www.wirfs-brock.com\/allen\/?p=166"},"modified":"2017-09-22T21:03:10","modified_gmt":"2017-09-23T05:03:10","slug":"a-javascript-optional-argument-hazzard","status":"publish","type":"post","link":"https:\/\/wirfs-brock.com\/allen\/posts\/166","title":{"rendered":"A JavaScript Optional Argument Hazard"},"content":{"rendered":"

My recent post on testing for negative 0 in JavaScript<\/a> created a lot of interest.\u00a0 So today, I\u2019m going to talk about another bit of JavaScript obscurity that was also inspired by a Twitter thread.<\/p>\n

I recently noticed this tweet go by:
\n\"\"
\nThis was obviously a trick question.\u00a0 Presumably some programmer expected this expression to produce an array like [1, 2, 3]<\/code> and it doesn\u2019t. Why not? What does it actually produce?\u00a0 I didn\u2019t cheat by immediately typing it into a browser but I did quickly look up something in my copy of the ECMAScript 5 Specification<\/a>. From the spec. it appeared clear that the answer would be:<\/p>\n

\n
[1, NaN, NaN]<\/pre>\n<\/div>\n
I then typed the expression into a browser and that was exactly what I got.\u00a0 Before I explain why, you may want to stop here and see if you can figure it out.<\/p>\n
OK, here is the explanation. parseInt<\/code> is\u00a0 the built-in function that attempts to parse a string as a numeric literal and return the resulting number value. \u00a0So, a function call like:<\/p>\n
\n
var n = parseInt("123");<\/pre>\n<\/div>\n
should assign the numeric value 123<\/code> to the local variable n<\/code>.<\/p>\n
You might also know, that if the string can\u2019t be parsed as numeric literal, parseInt<\/code> will return as the result the value NaN<\/code>.\u00a0 NaN<\/code>, which is an abbreviation for \u201cNot a Number\u201d, is a value that generally indicates that some sort of numeric computation error has occurred.\u00a0 So, a statement like:<\/p>\n
\n
var x = parseInt("xyz");<\/pre>\n<\/div>\n
assigns NaN<\/code> to x<\/code>.<\/p>\n
map<\/code> is a built-in Array method that is in ECMAScript 5 and which has been available in many browsers for a while. map<\/code> takes a function object as its argument.\u00a0 It iterates, over each element of an array and calls the argument function once for each element, passing the element value as an argument. It accumulates the results of these function calls into a new array.\u00a0 Consider this example,<\/p>\n
\n
[1,2,3].map(function (value) {return value+1})<\/pre>\n<\/div>\n
it will return a new array [2,3,4]<\/code>. It is probably most common to see a function expression such as this passed to map<\/code> but it is perfectly valid to pass an already existing function object such parseInt<\/code>.<\/p>\n
So, knowing the basics of parseInt<\/code> and map<\/code> it is pretty clear that the original expression was intended to take an array of numeric strings and to return a corresponding array containing the numeric value of each string.\u00a0 Why doesn\u2019t it work?\u00a0 To find the answer we will need to look more closely at the definition of both parseInt<\/code> and map<\/code>.<\/p>\n
Looking at the specification of parseInt<\/a> you should notice that it is defined as accepting two arguments.\u00a0 The first argument is the string to be parsed and the second specifics the radix of the number to be parsed.\u00a0 So, parseInt(\u201cffff\u201d,16)<\/code> will return 65535<\/code> while parseInt(\"ffff\"\u201d,8)<\/code> will return NaN<\/code> because \"ffff\"<\/code> doesn\u2019t parse as an octal number.\u00a0 If the second argument is missing or 0<\/code> it defaults to 10<\/code> so parseInt(\"12\",10)<\/code>,\u00a0 parseInt(\"12\")<\/code>, and parseInt(\"12\",0)<\/code> all produce the number 12.<\/p>\n
Now look carefully at the specification of the map method<\/a>.\u00a0 It refers to the function that is passed as the first argument to map<\/code> as the callbackfn<\/em>.\u00a0 The specification says, \u201cthe callbackfn<\/em> is called with three<\/em> arguments: the value of the element, the index of the element, and the object that is being traversed.\u201d Read that carefully.\u00a0 It means that rather than three calls to parseInt<\/code> that look like:<\/p>\n
\n
parseInt("1")\r\nparseInt("2")\r\nparseInt("3")\r\n<\/pre>\n<\/div>\n
we are actually going to have three calls that look like:<\/p>\n
\n
parseInt("1", 0, theArray)\r\nparseInt("2", 1, theArray)\r\nparseInt("3", 2, theArray)\r\n<\/pre>\n<\/div>\n
where theArray<\/code> is the original array [\"1\",\"2\",\"3\"]<\/code>.<\/p>\n
JavaScript functions generally ignore extra arguments and parseInt<\/code> only expects two arguments so we don\u2019t have to worry about the effect of the theArray<\/code> argument in these calls.\u00a0 But what about the second argument?\u00a0 In the first call the second argument is 0<\/code> which we know defaults the radix to 10 so parseInt(\"1\",0)<\/code> will return 1<\/code>.\u00a0 The second call passes 1<\/code> as the radix argument.\u00a0 The specification is quite clear what happens in that case.\u00a0 If the radix is non-zero and less than 2 the function returns NaN<\/code> without even looking at the string.<\/p>\n
The third call passes 2<\/code> as the radix argument.\u00a0 This means that the string to convert is supposed to be a binary number consisting only of the digit characters \"0\"<\/code> and \"1\"<\/code>. The parseInt<\/code> specification (step 11) says it only tries to parse the substring to the left of the first character that is not a valid digit of the requested radix.\u00a0 The first character of the string is \"3\"<\/code> which is not a valid base 2 digit so the substring to parse is the empty string. Step 12 says that if the substring to parse is the empty string, the function returns NaN<\/code>. So, the result of the three calls will be 1<\/code>, NaN<\/code>, and NaN<\/code>.<\/p>\n
The programmer of the original expression made at least one of two possible mistakes that caused this bug. The first possibility is that they either forgot or never knew that parseInt<\/code> accepts an optional second argument.\u00a0 The second possibility is that they forgot or never knew that map<\/code> calls its callbackfn<\/em> with three arguments. Most likely, it was a combination of both mistakes. The most common usage of parseInt<\/code> passes only a single argument and most functions passed to map<\/code> only use the first argument so it would be easy to forget that additional arguments are possible in both cases.<\/p>\n
There is a straight forward way to rewrite the original expression to avoid the problem. Use:<\/p>\n
\n
["1","2","3"].map(function(value) {return parseInt(value)})<\/pre>\n<\/div>\n
instead of:<\/p>\n
\n
["1","2","3"].map(parseInt)<\/pre>\n<\/div>\n
This makes it clear that the callbackfn<\/em> only cares about a single argument and it explicitly calls parseInt<\/code> with only one argument.\u00a0 However, as you can see it is much more verbose and arguably less elegant.<\/p>\n
After I tweeted about this, there was an exchange about how JavaScript might be extended to avoid this problem or to at least make the fix less verbose. \u00a0Angus Croll (@angusTweets)<\/a> suggested the problem could be avoided simply by using the Number<\/code> constructor as the callbackfn<\/em> instead of parseInt<\/code>. Number<\/code> called in this manner will also parse a string argument as a decimal number and it only looks at one argument.<\/p>\n
@__DavidFlanagan<\/a> suggested that perhaps a mapValues<\/code> method should be added which only passes a single argument to the callbackfn<\/em>.\u00a0 However, ECMAScript 5 has seven distinct Array method that operate similarly to map<\/code>, so we would really have to add seven such methods.<\/p>\n
I suggest the possibility of adding a method that might be defined like:<\/p>\n
\r\nFunction.prototype.only = function(numberOfArgs) {\r\n   var self = this; \/\/the original function\r\n   return function() {\r\n      return self.apply(this,[].slice.call(arguments,0,numberOfArgs))\r\n   }\r\n};\r\n<\/pre>\n
This is a higher order function<\/a> that takes a function as an argument and returns a new function that calls the original function but with an explicitly limited number of arguments.\u00a0 Using only<\/code>, the original expression could have been written as:<\/p>\n
\n
["1","2","3"].map(parseInt.only(1))<\/pre>\n<\/div>\n
which is only slight more verbose and arguably retains a degree of elegance.<\/p>\n
This led to a further discussion of curry functions<\/em> (really partial function application<\/a>) in JavaScript. Partial function application takes a function that requires a certain number of arguments and produces a new function that takes fewer arguments. My only<\/code> method is an example of a function that performs partial function evaluation.\u00a0 So is the Function.prototype.bind<\/code> method that was added to ES5. Does JavaScript need such additional  methods?\u00a0 For example, a bindRight<\/code> method that fixes the rightmost arguments rather than the leftmost.\u00a0 Perhaps, but what does rightmost even mean when a variable number of arguments are allowed?\u00a0 Probably bindStartingAt<\/code> that took an argument position would be a better match to JavaScript.<\/p>\n
However, all this discussion of extensions really misses the key issue with the original problem. In order to use any of them, you first have to be aware of the optional argument mismatch between <\/em>map<\/code> and <\/em>parseInt<\/code>.<\/em> If you are aware of the problem there are many way to work around it.\u00a0 If you aren\u2019t aware then none of the proposed solutions help at all.\u00a0 This really seems to be mostly an API design problem and raises some fundamental questions about the appropriate use of optional arguments in JavaSript.<\/p>\n
Supporting optional arguments can simplify the design of an API by reducing the total number of API functions and by allowing many users to only have to think about the details of the most common use cases.\u00a0 But as we see above, this simplification can cause problems when the functions are naively combined in unexpected ways.\u00a0 What we are seeing in this example is that there are really two quite different use cases for optional arguments.<\/p>\n
One use case looks at optional arguments from the perspective of the caller. The other use case is from the perspective of the callee.\u00a0 In the case of parseInt<\/code>, its design assumes that the caller knows that it is calling parseInt<\/code> and has chosen actual argument values appropriately.\u00a0 The second argument is optional from the perspective of the caller.<\/em> If it wants to use the default radix it can  ignore that argument.\u00a0 However, the actual specification of parseInt<\/code> carefully defines what it (the callee) will do when called with either one or two arguments and with various argument values.<\/p>\n
The other use case is more from the perspective of a different kind of function caller. A caller that doesn\u2019t know what function it is actually calling and that always passes a fixed sized set of arguments. The specification of map<\/code> clearly defines that it will always pass three arguments to any callbackfn<\/em> it is provided. Because the caller doesn\u2019t actually know the identify of the callee or what actual information the callee will need, map<\/code> passes all available information as arguments.\u00a0 The assumption is that an actual callee will ignore any arguments that it doesn\u2019t need. \u00a0In this use case the second and third arguments are optional from the perspective of the callee.<\/em><\/p>\n
Both of these are valid optional argument use cases, but when we combine them we get a software \u201cimpedance mismatch\u201d.\u00a0 Callee optional arguments will seldom match with caller optional arguments. Higher order functions such as the bind<\/code> or only<\/code> methods can be used to fix such mismatches but are only useful if the programmer is aware that the mismatch exists. JavaScript API designers need to keep this mind and every JavaScript programmer needs to take extra care to understand what exactly will be passed to a function used as a “call back”.<\/p>\n
Update 1<\/strong>: Correctly credit Angus Croll for map(Number) suggestion.<\/p>\n","protected":false},"excerpt":{"rendered":"
My recent post on testing for negative 0 in JavaScript created a lot of interest.\u00a0 So today, I\u2019m going to talk about another bit of JavaScript obscurity that was also inspired by a Twitter thread. I recently noticed this tweet go by: This was obviously a trick question.\u00a0 Presumably some programmer expected this expression to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[32,15,60,13,34],"_links":{"self":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/166"}],"collection":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/comments?post=166"}],"version-history":[{"count":37,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/166\/revisions"}],"predecessor-version":[{"id":805,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/166\/revisions\/805"}],"wp:attachment":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/media?parent=166"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/categories?post=166"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/tags?post=166"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}