Coercion Rules & Operators

[00:00:00]
>> Will Sentance: Folks, here are our 3 coercion rules, or 3, sorry, 3 coercion flows: to number, and people, I'm not too concerned about the individual rules here, besides to maybe have a smile at some of them, because I'm more interested here that we have 2 or 3 major funnels that can convert, coerce stuff into a number, a string, or a true and false, and each of them is kicked off automatically by a range of operators and or actions.

[00:00:37]
So let's go through them. But remember that this in the end is going to be something you will often just go and experiment with to see, ah, that one's taken it that way. And ideally, you want to write your code primarily to minimize the amount of these sort of automations that are happening without your official consent, without saying, please go and make this coercion happen. But we have our to number, we saw there, our string 3 going to 3, our string minus 3 going to -3, decimals, our true and our false, our 1 and our 0, our null goes to 0, and then we have undefined, that goes to a number of type, not a number, that is a number.

[00:01:26]
Amazing. Actually, by the way, some of these things, they may sound like JavaScript quirks, they're actually very typical of many programming languages. These are actually features of the International Standards Organisation for programming languages that chooses to, for example, treat a particular non-number, no, non-numeric value number as a useful tool in a programming language. You want to have a thing that is a number, such that when it's coerced to a number, this is a value that's available as a number type.

[00:02:05]
Type number, but it's not actually of numeric value. That's a useful tool, so we can kind of recognize that these are attempts by designers of languages to have an answer to many of these different challenges that go into particularly working with types. As string, we can coerce pretty much anything into a stringified version of that one. That one's actually not too bad, is it, right? Numbers into string, that's pretty much like, take the data type as we see it presented in a console and return it as a string, not so bad.

[00:02:44]
To boolean, in theory, not terrible, you've got the non-value data types, null, undefined, and not a number, coercing to false, 0 and an empty string. We saw how that caused a clash for us, and then everything else is true. So those are our big 3 coercion conversions, 3 coercion processes, and they do get kicked off by a wide range of operators. Our math one to number, our unary one to number, lovely, our plus to string, unless both are numbers.

[00:03:22]
Our relational, first to number, and then to string, where if you're doing to string, you then do an alphabetical roughly comparison, not quite, but more of a Unicode position comparison. Our looser equality just goes any direction, left or right. Avoid our conditionals, and then to boolean, and then our string either via the browser, passing data in, or via our string template or the string method call toString.

[00:03:56]
We only have 3 things to take away from this: our 3 coercion journeys that can happen between our data types, and then the things that can kick those off. The details of the exact coercions that happen within them are to a smaller extent, the work that you will do when you go and experiment or check in documentation, or in the fascinating grid of coercions that is available for you to assess within JavaScript.

[00:04:29]
But so we're done, except we're not. Let's make sure we do one more thing. Question's done. Before we go further, let's just check that our user is valid first. We can't have anyone buying. We're done with our coercions though, sort of, not really. But I hope I didn't go, as I say, I hope I didn't go too fast, not out of actual concern, but rather that to some extent, that is our core. It's a reason why hard parts hasn't per se, always had a portion around type coercion, because, yes, there is this core funnel of to number, to string, to boolean that's kicked off by operators on their operands.

[00:05:13]
That's interesting. But we know that quite a lot of that is just a bunch of rules, and rules ain't mental models. Rules are things you go and check at the moment when it's not quite working. There ain't some deeper set of rules besides that you can kick off those three actions based on different operators, and some of them are pretty reliable, like the math to number, but some of them, like loose equality, just have so many different variations, and there ain't some sophisticated, well, we're doing it because of this.

[00:05:44]
Some of that truly is legacy. We did it that way when we had, you know, famously, you know, under 10 days to release the language in '95, and it's still that way. Okay, so that's the reason I've always sort of hesitated. However, so well done, coercion's done. However, before we go further, let's just check that our user that we are submitting, who's doing the submission here, is actually a valid user.

[00:06:13]
So, we can't have any person buying. Let's make sure we have somebody buying who has the credentials. So our user is going to submit their name and their ID, and then we're going to compare that to our only acceptable user stored. And user admitted. Oh no, sorry, stored and user stored, and if they are the same objects, same contents, then we are going to allow them to purchase. Does this feel like a secure approach?

[00:06:45]
Perhaps the least secure approach in history, although to be fair, not a million miles away from how authentication is done. We are going to have some data describing the user, and then the user will enter some data, and we will do a secure comparison, but not a million miles away. But here we're going to do it without any of that security. In practice it's done securely, but we are essentially going to be comparing the data from the user that has been entered into our form, which we're going to make, and then we're going to compare it to our data that is stored in memory.