Transcript from the "Implicit Coercion" Lesson
>> Kyle Simpson: There is a temptation to believe, and it's sort of a cult feeling among the community, most developers tend to think that implicit mechanisms are magical. That when something happens underneath the scenes, and it wasn't obvious, then it's some sort of magic. And we tend to equate magic with bad, evil, like this is not good because I can't understand what's happening.
[00:00:26] And this is a predominant reason why that anti-coercion prospective exists is because people feel like the implicitness of coercion is the downfall where they point to explicitness of type casting in something like Java or C++. And then they say, you would never automatically convert an integer into a float or whatever.
[00:01:08] Implicitness, and we're not dealing with functional programming here. This is not this course, that's a different course. Here's a plug, you can check on my functional programming course. But within functional programming, you use abstraction all over the place. And it turns out that the declarative style of coding is actually more implicit.
[00:01:29] So implicitness is not bad, it is the proper usage of obstruction. In other words, we want to hide key unnecessary details, why? Because that re-focuses the reader on the important stuff. We're not distracting them with the stuff that they don't need. We wanna focus them. We wanna increase the clarity of the code by re-focusing.
>> Kyle Simpson: So here, if I'm writing string to make it super obvious that I'm gonna make this thing into a string, I don't know, I think that's distracting. I think I would just drop in the number and be perfectly happy, because I know that number is never in any of those corner cases where something could be weird.
[00:03:17] Here's another example, the less than operator, we talked about how it coerces things into numbers. Sometimes you wanna go ahead and make sure that both of them are a number so that you don't get something weird. For example, if both of them are strings, it doesn't turn them both into numbers.
[00:03:34] The less than operator does an alphanumeric comparison. So there's a corner case, if you could possibly have a less than applied to two strings, you probably do wanna make sure that they're both numbers first. But if I'm in a place of the code where I know at least one of them is definitely a number?
[00:03:52] Well then, I know the other one's gonna become a number, so maybe it's not necessary to force you to read the fact that I'm making them both numbers. Maybe it's okay, to let that less than operator do the coercion form. These are not hard and fast rules, these are trying to train you to think like this to analyze.
[00:04:10] And if you are in a place where you have the choice to use coercion but it's not obvious, it's within your purview to make it obvious. Make it obvious that they're both numbers and therefore, I don't need to worry about explicitly casting them. It's just already obvious that they're both numbers.
[00:04:27] If you communicate that intent, it's not gonna trip up other readers of the code.
>> Kyle Simpson: Really, the question is, is showing these extra details helpful to the reader or not? Sometimes yes, sometimes no.
>> Kyle Simpson: Basically, I'm asking you to be critical, analytical thinkers, to be an engineer and not a code monkey, okay?