exploring javascript type auto-coercion (and its pitfalls)

gistfile1.txt

// **********
// NOTE: this is a stupid trivial example illustrating automatic
// type-coercion, not an example of the kind of data-structure logic
// you'd ever actually use. don't miss the forest for the trees.
// Read down in the comment thread for 'myCoolString' for a slightly
// more sensible example.
//
// NOTE #2: this gist thread was spawned from a twitter discussion
// about `parseInt(0/1,19)==18`:
// https://twitter.com/getify/status/221009838006747136
// **********


var myObj = {
   _val: [10,5,7,9,-1,4,13,6],
   toString: function(){
     return ""+Math.max.apply(this,this._val);
   }
};

parseInt(myObj); // 13 ==> this is part of what makes javascript awesome

Let me be slightly more formal with my assertion about the composability of underlying behaviors.

Let's call f() the function that turns an int to string, and let's call g() the function that turns string to an int (as much as possible, with LTR parsing).

There's an assumption I think being made that a "correct" language would ensure g(f(x)) == x. For some values of x, that's certainly true of javascript. But some values of x, which are still of type number, aren't composable like that. One such value is Infinity, another is NaN.

For that to be true, g() would have to have special-case behavior that is not only not present in the language, but if it were present, it would create even harder to "know" (aka, find/debug) behavior than we currently have.

Imagine g() were defined as:

• look for "Infinity", and assume they want the special Infinity numeric value parsed out (but wait, Infinity is not an int, it's a number, so oops... we have a contract violation).
• look for "NaN", and assume they want the special NaN numeric value parsed out (but wait, NaN is also not an int, it's a number... oops).
• look for "-Infinity", and assume.... oops
• ...

And then we'd have to consider whether we want to allow g() to operate case-insensitively or not.

And even if we had this behavior, we'd still have just as many possible WTF's, just of different substance. For instance:

parseInt("Infinity Broadcasting") == Number.POSITIVE_INFINITY  // seriously, wtf? this should be NaN
parseInt("-Infinity Broadcasting") == Number.NEGATIVE_INFINITY

And then, we'd have to consider whether this special behavior was true no matter what radix/base we pass to parseInt(). For instance, if I say, parseInt("Infinity",26), would I rather get Number.POSITIVE_INFINITY, or would I instead expect 224651640?

I have no "respect" for any language. I'm not even sure what that means. Technology decisions are tradeoffs. The choice of one language over another is a matter of choosing the best tool for the job at hand. I absolutely respect the toolmakers, but the tools are just tools. If you point out a flaw with my tool, I may argue that said flaw is a feature, but neither my tool nor I shall feel disrespected.

I guess that parseInt(1/0,19)==18 is just my own personal semantic WTF. I'm sure if you're experienced enough with JavaScript, you can look at a function that (a) purports to produce integers that match its parameters, (b) accepts Infinity as one of the parameters, and (c) produces the number 18, and use it as an example of the greatness of JavaScript.

Many of us continue to shake our heads, and struggle to understand. Perhaps one day we will become enlightened. Then shall we understand parseInt(1/0,19)==18. Until then, we trudge along in the darkness of our stupidity.

@bhudgeons
parseInt(1/0,19)==18 is clearly a semantic WTF... for pretty much everyone, myself included. There's never been an argument about that.

There are plenty of other semantic WTFs too. My personal "favorite" is typeof NaN == "number".

The question has been, is the language "flawed" by allowing that (or rather, not ensuring some yet-to-be-well-defined alternative)? And more importantly, if we were to consider changing the language to "fix" the "flaw", would we REALLY be better off, or is that just a "grass is always greener" conundrum?

I've been trying to illustrate that all the alternatives are worse. You're not in the "darkness of stupidity" because you disagree. You just value different things from the language than I do.

:)

I woud use valueOf here instead of toString.