Corner Cases of Coercion

[00:00:00]
>> Kyle: Because all languages have type conversions, that means all languages have corner cases, including JavaScript. It is interesting that people like to use JavaScript's corner cases as ammunition against the language as a whole. Just putting blinders on and pretending that other languages don't have those corner cases and we can't make work videos about C++, for example, cuz we definitely can, right?

[00:00:25]
It is impossible to design a system that won't have corner cases. JavaScript has some corner cases. Rather than making wap videos about them, we should learn those corner cases and learn how to effectively manage and work around them.
>> Speaker 2: Do they have more corner cases than other languages?

[00:00:39]
>> Kyle: That's an interesting question, but not one that I think anybody could effectively answer. Because what is even more mean, and we're just gonna like keep up account. How can you tell whether this is the distinct different quark or the same corner case from a different angle? I'm not sure that you could really do that sort of account.

[00:00:57]
And to the larger point of your question, the only language that I even remotely have understanding of is JavaScript. So I can't tell you whether it's more or less corner casey than Python. But I know JavaScript has corner cases, and I know you can work around them. Here's an example of some of these corner cases.

[00:01:16]
A lot of them have to do with numbers, as I said. Here we've got number of empty string, remember that one, that's the root of all evil. We'll talk about that more in a second. Knowles and undefined have some weird corner cases. Essentially a lot of the falsy values becoming numbers, those there were a lot of the corner cases ar.

[00:01:34]
We could have eliminated most of those if we just not made empty string becomes zero. Most of these would go away.
>> Kyle: Down at the bottom there is an interesting example, almost nobody ever does this. But if you construct an instance of the boolean object and you give it the primitive value false, it is going to behave as if it is truthy, because we don't do a two primitive on it, we just ask is it on the falsy list or not?

[00:02:03]
So it is a falsy object, right?
>> Kyle: Yet another illustration of why you should never use those particular fundamentals with the Nuki word.
>> Kyle: All right, let's talk about that root of all coercion evil, just to make sure we're absolutely clear here. Not only does the empty string become zero, but any string that's full of white space also becomes zero.

[00:02:31]
Because the two number operations first strips off all leading and trailing whitespace before doing its coercion. So all examples of white space strings of all forms, still all end up producing that same zero.
>> Kyle: Literally, if I could time travel and fix any one thing about JavaScript, this is the thing I'd fix.

[00:02:54]
I'd go back and tell Brendon, no, no, no, that's a terrible idea. Don't make empty string become zero, make it become name. All these other problems would fix themselves. By the way, there are corner cases that are not as obvious, because we're not dealing with our typical operations.

[00:03:12]
So, remember I said that I thought that the numberification or numerification or whatever that word is, I'll decide on some word at some point. But whatever that word is, to numbering a boolean I said to you, 1s and 0s are a bad idea. And probably, all of you said, no, they're a great idea.

[00:03:33]
Well, here's one such example. 1 less than 2, we all know mathematically that that is the case, and so it makes sense that JavaScript gives us a true. 2 less than 3 is also true. But then we try 1 less than 2 less than 3, and we get true, and we think well JavaScript is just smart and doing exactly the right thing.

[00:03:55]
Not exactly, because what's actually happening there is an accident. What's actually happening is that 1 less than 2 gets evaluated first, which gets evaluated to true line 9. And then because you have a non-numeric being used with the less than operator, it's gonna try to turn it into a number.

[00:04:14]
So it's gonna turn it into the number 1, and you accidentally get that 1 is less than 3, that's the reason why true works. And accidents are not a good foundation upon which to build your programs. Cuz let's watch what happens in the next example. We try the 3 greater than 2, and the 2 greater than 1, but oops, 3 greater than 2 greater than 1, that fails.

[00:04:34]
Because 3 greater than 2 is true. True greater than 1 is 1 greater than 1, which is false.
>> Kyle: So I think it's a terrible idea for booleans to implicitly coerce themselves to numbers. And any programming style from 1970 onward, that has relied upon the ability to take something that's boolean and subtract or add it or something, I think, has been taking advantage of that hack, but basically making worse of code.

[00:05:06]
I would make the number coercion of brilliant be name if I could fix things.