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

@bhudgeons

In the tweet you referenced, I said that...

I mistakingly put the wrong tweet-link, and have since corrected it. In the correct tweet, you said

I'd question the advisability of not returning an error for parseInt('i'm dumb',19)==18

So I was curious if you still felt that way. Sounds like you don't.

If coercion of any number value into its string value with toString, followed by a re-conversion of the resulting string to an int is what you want (which I can't imagine it would ever be)

No, that's missing my point. What is quite often (an easy scenario to imagine, as I explained earlier) "what [i] want" is to make sure that I get an int out, no matter whether it starts out as an int, or a string representing an int, or a string that is int-like on its left-hand side. You could rename parseInt() to makeIntNoMatterWhat() for the purposes of this discussion.

But the point is, most javascript devs expect that (because it's true everywhere else) if you have an int and you need to use it as a string (even if that use is to turn around and make it an int again!), there's no problem, because javascript coerces your int to a string quite nicely.

If in all other places in javascript, ints got coerced to strings automatically and perfectly, but in this one case, where I pass an int to a function that is expecting a string and that function wants to be an asshole and say "no, I won't auto-coerce for you. screw you.", THAT function would be wholly out of place in javascript.

I can't understand why that consistency point doesn't seem to matter to you? Why is the semantics of the name of the function overriding the desire to have consistency in how things are coerced?

I can't quite get my head around how someone can look at parseInt(1/0,19)==18 and not laugh, much less think that it is preferred behavior, much less that it is "functioning smartly."

I have said it before, and I'll repeat: what I like is that javascript is behaving consistently here (the coercion of a number to a string), just like using that number (aka Infinity) anywhere else in code that expects strings gives me, in fact, a coerced string.

The side effect of javascript behaving consistently here is that it creates a higher-order semantic "WTF" for you. That doesn't mean javascript isn't functioning logically (it is!), it means it's not functioning how you would describe "sensibly".

I prefer to look at the lower level behavior, rather than the higher-order composite side effect, for reasoning. The lower level behavior is quite reasonable; what's wrong is not that. What's wrong is that a developer is composing lower level behaviors in an unreasonable way, and expecting a reasonable outcome.

I don't understand how fixing the method to produce results that are more mathematically correct yields a reduction of your programming freedom.

parseInt() isn't a mathematical function, so it has no such notion of "mathematically correct" operations.

"Fixing" this "problem" would mean one of two things:

1. create an exception only for parseInt(), simply because it's name and the documentation imply some semantics which seems to override the importance of consistency of coercion behavior language-wide.
2. disable all such auto-coercions (maintaining consistency!) and throw the baby out with the bathwater, such that everywhere that I want an int to be a string, I have to manually cast it as such.

Both of those options are, IMHO, more evil than the evil of having to understand where coercion is "safe" and where it's "unsafe". The rules for safe coercion are so limited and relatively easy to learn compared to learning where all these rabbit-hole exceptions would be, I just can't understand how anyone with even a modicum of respect for the language would think that's a better path. But perhaps that's where the failing is, that I'm assuming respect where it's lacking. :)

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.