Explicit coercion happens when it’s obvious from the code that one type is being converted to another. Kyle shares a few code examples demonstrating ways to explicitly coerce values from String to Numbers and vice versa.
You actually have to do that through some other operation in the language, so we wanna talk about what those things look like. And what I'm going to do here is I'm going to divide up the possible ways of doing these things into two categories. These are my own terms that I use to try to keep things separate in a way that's conceptually useful to people. So I'm gonna define them into two categories, Explicit and Implicit. That is Explicit Coercion, and Implicit Coercion. And I will define my working definition for what I mean by that. Explicit is that it means that it's obvious from the code that you're doing it.
If you can look at a piece of code, and it is obvious that the end result of that piece of the code is to convert from one type to another, then I call that Explicit Coercion. And Explicit Coercion maps almost one-for-one with what you think of with type conversion in any other language. Static type languages, like C++ and Java. When you have to cast one number to another, or so forth. It's obvious that you're doing that, therefore those are Explicit Conversions, Explicit Coercions.
That's absolutely required in our programs. It would be nonsense to suggest that you could write a production quality App that would never have in any way, shape or form a need to go from a number, to a string, or whatever. It just happens all over the place. It happens differently in different programs, and I'm not saying it happens with every single line of your code, but it is definitely something that just seems to be practically almost required for reasonable programs. If it's required for reasonable programs, and every other language does it, it shouldn't be something that we label as negative.
And yet a lot of people do seem to label these things as negative, they seem to think that these things behave in some sort of buggy way, or they're not what they oughta be. So let's take a look at some different examples of it. The first one we'll look at is when we're going between strings and numbers, in either direction. Between strings and numbers in either direction, what do the Explicit Coercions look like. This is gonna directly answer some questions that were asked in the chatroom a few moments ago. So if you're listening along, this is the answer. So if I have a string value, like string 123, like quote 123 like I have on line one.
And I want to convert, or coerce it to a number, there's a couple of options, the first I'll highlight is one called parseInt. Now you'll notice I'm using parseInt, I'm passing in a string value here, I'm saying parseInt with that second argument there is comma 10. That indicates that I wanna do things in Base 10 number system. There's a lot of people that call parseInt a coercion. Strictly speaking, it's not a coercion, it's a parse. 'Cause that's what its name is, it's what it's actually doing.
If you give it the string 123, you're gonna end up with number 123. But if you give it the string 123PX, you're still gonna end up with the number 123 because of what it's actually gonna do is parse from left to right in some Base system. So it's useful if you wanna parse number values out of string values. That's what it's for, that's only what it's for. I would not recommend thinking of parseInt quote 123 as a coercion tool, although many people call it that.
So it's kind of in the family of coercion, but it is not, strictly speaking, a coercion. Strictly speaking it's a parse, which is useful, but you should keep those two separate in your mind. So let's move to something that really is legitimately, a coercion. Line five, I'm using the Number function, without the new keyword. I pass in a string value like quote 123 and I get the number 123 out. That is an Explicit Coercion. It looks an awful lot like typecasting from some languages, doesn't it? If you've seen typecasting in languages like C and C++, it looks an awful lot like that.
Some people used to put the parentheses around the type, and then leave the number after it. And some people would put the type, and then the parentheses around the value. In that latter form of it, it looks exactly like what we're doing here. Although this isn't actually a cast, it's actually a function call. But it looks a lot like what you're familiar with in terms of Explicit Type Coercion. I would endorse line five as how I think preferably, you would want to do Explicit Conversion from something to a number.
Use the Number function. When I look at line five, it is clear and unequivocally, there's no debate, what it does is it makes a number out of something. It does what it says on the label. So that's why I call that an Explicit Coercion. Now, line eight, let's look at line eight. I'm putting the + symbol, if you see right there, the + symbol in front of the foo identifier. And it is also going to end up resulting in the number 123.
The + operator, when used in, and here's a fancy five dollar word, the unary form. That is, an operator that only receives one operand. The unary operator form of +, if you looked it up in the spec, it is defined with one, and only one job. It just does one thing. And you can probably guess what it is. It's to coerce from anything to a number. It invokes the toNumber algorithm, the same way the Number function invokes the toNumber algorithm.
They both do the exact same thing. They invoke the toNumber abstract algorithm. So both of these would be in the family of what we call explicit. 'Cause they're both defined explicitly to do the thing. But whether or not line eight actually is what we should consider explicit, is perhaps somewhat up to debate. And it emphasizes the major point I want you to take away from this slide. Which is that explicit, the terms explicit and implicit, are not objective, they are subjective.
They are relative terms. They are relative to the developer. When I look at this piece of code, line five, there's probably not a lot of people that would debate what line five is doing. But line eight, ehhh. If I teach you what it is, and you know what it is, from then on it's totally explicit to you. But if you've never seen that usage of it before, you might stop and give it some pause, and therefore it might not be quite so explicit to you. The takeaway here is you and your team, and then the other people that you expect to decide how to use things in your codebase.
You have to make that decision. Just like you decide on other style guide things, this is another idiom for your programming, how do you handle coercions? And your team might decide that + is more preferable, and that's totally fine with me. Or you might decide to use the Number function. And that's also totally fine to me. You should agree on it, and you should do it the same everywhere. Mixing and matching, perhaps maybe not such a great idea. So it's kind of in this debatable category, whether or not it's explicit, but from the spec perspective it's definitely an explicit mechanism.
But it's up to you, it's up to you to decide. Now what about the other direction? If we start out with a number, how do we get a string out of it? Well, we can start out with line 11 with 456, and in line 12 I call the toString method. Remember, I said there is a toString method so I can actually call that thing directly. And I'm going to get quote 456. Technically speaking, the toString method did not invoke the toString primitive operation.
It looks like it did, but it didn't. What it actually did was just straight-up shortcut the two primitive and go straight to the toString method. And you either get what you want out of the toString method, or you get something bad out of the toString method, but there's no other thing. This is not a magical way to invoke the capital T ToString abstract alteration. It's a way to shortcut it, and go directly to a method that you would find helpful, in most cases you would find helpful.
I think most people would argue that line 12 is fairly explicit, in what it's doing. It's pretty clear, it's taking something and turning it into a string. So it definitely does fall in the family of Explicit Coercion, but there is something kind of subtle about the toString method that we should be aware of. I'm calling the toString method on a primitive number value. Primitive values do not have methods and properties on them.
That's not strictly coercion, but I'd put it in the same family as coercion. 'Cause it's taking something from it's primitive type, and boxing it into this other thing, which is a sub-object type. So it's in the family of coercion. And if you asked is that an implicit system or an explicit system, I'd have to say that that boxing is an implicit mechanism. It's totally hidden under the covers. You might call line 12 implicitly explicit.
Or maybe explicitly implicit. It's kind of a mixture of both. I still endorse it, I'm not saying it's bad. Which is a foreshadowing to the conclusion that we're gonna come to later, which is I don't think all implicit coercions are bad. A lot of people think they're all evil. This is one of those cases where I think implicit coercion is actually useful for us. But I'm not sure I would totally endorse line 12, because we have the option of line 15. And line 15 literally does invoke the toString primitive algorithm which ends up calling the toString method for us without any of that boxing.
And that's exactly what we want out of this. And we get the end result, quote 456. So I'd endorse line 15 and line five, as, in my opinion, the most preferable form of going in either direction between strings and numbers
Note: This course was created by Frontend Masters. It was originally released on 8/29/2015. We're pleased to host this training in our library.
- Primitive types: undefined, string, number, boolean, and object
- Special values: NaN and negative zero
- Natives: Regex and date
- Functions: toString, toNumber, and toBoolean
- Implicit coercion
- Explicit coercion
- Strings, numbers, and booleans
- Operators: Double equal and triple equal