Transcript from the "Corner Cases of Coercion" Lesson
>> Speaker 2: Do they have more corner cases than other languages?
>> 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: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.
[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: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.