The JavaScript type coercion algorithm
-
That's it. That's the meme.
TL;DR do not use
== -
That's it. That's the meme.
It's so crazy to me that they convert from string to int and not the other way round.
-
TL;DR do not use
==Common practice since forever
-
It's so crazy to me that they convert from string to int and not the other way round.
"1e2" == 100 I guess is the reason? I mean if there were some "reasons" to begin with
-
"1e2" == 100 I guess is the reason? I mean if there were some "reasons" to begin with
There surely are strings that can be converted into numbers (even something as simple as "1"). But in general, when languages do implicit conversions, they do it towards the more general type.
For example, if I do
1.1 == 1in pretty much any language that has separate float and int types, the integer gets casted into a float (from more specific to more general type) and the comparison returns false. It would be utterly ridiculous if the language auto-casts the float to int and then returns true.JS does just that. Instead of casting the more general number into a string and comparing that, it goes the other way round.
Every number has an equivalent string representation, not every string has an equivalent number representation.
-
That's it. That's the meme.
if you hate JS and think it's dumb, but still have to use it, look into Eloquent Javascript (free) https://eloquentjavascript.net/ and the mozilla docs https://developer.mozilla.org/en-US/docs/Web/JavaScript.
Eloquent JS is written by someone who also hates JS, but understands it very well.
I used them while I worked on the Microtonal Music Grid (still in progress)
-
That's it. That's the meme.
Just use
=== -
Common practice since forever
most linters since like jshint as well catch it
-
There surely are strings that can be converted into numbers (even something as simple as "1"). But in general, when languages do implicit conversions, they do it towards the more general type.
For example, if I do
1.1 == 1in pretty much any language that has separate float and int types, the integer gets casted into a float (from more specific to more general type) and the comparison returns false. It would be utterly ridiculous if the language auto-casts the float to int and then returns true.JS does just that. Instead of casting the more general number into a string and comparing that, it goes the other way round.
Every number has an equivalent string representation, not every string has an equivalent number representation.
Not quite. As the previous commenter said, every string has at least one string representation (i.e. 100 -> "100", "1e2"). So there's no sensible way to write a pure function handling that, you're just cooked no matter what you do.
-
Not quite. As the previous commenter said, every string has at least one string representation (i.e. 100 -> "100", "1e2"). So there's no sensible way to write a pure function handling that, you're just cooked no matter what you do.
Other languages handle that easily:
Implicit cast from number to string, explicit parsing in the other direction.
For comparisons as number, parse the string to a number and compare two numbers.
The main point of the implicit cast from number to string is to concattenate number to string, e.g.
print("testValue: " + testValue).Another option (e.g. taken by Python) is to acknowledge that there's no pure 1:n mapping in any direction between string and number, so any conversion between those two needs to be done explicitly. That's probably the most correct implementation, but it makes string concattenation annoying. But then again, f-strings and similar techniques make that problem pretty much obsolete.
-
Other languages handle that easily:
Implicit cast from number to string, explicit parsing in the other direction.
For comparisons as number, parse the string to a number and compare two numbers.
The main point of the implicit cast from number to string is to concattenate number to string, e.g.
print("testValue: " + testValue).Another option (e.g. taken by Python) is to acknowledge that there's no pure 1:n mapping in any direction between string and number, so any conversion between those two needs to be done explicitly. That's probably the most correct implementation, but it makes string concattenation annoying. But then again, f-strings and similar techniques make that problem pretty much obsolete.
Yeah I mean it's definitely possible to write a mostly sensible string-number equality function that only breaks in edge-cases, but at this point it's all kinda vibes-based mush, and the real question is like... Why would you want to do that? What are you really trying to achieve?
The most likely case is that it's a novice that doesn't understand what they're doing and the Python setup you describe does a better job at setting up guardrails.
I don't really see the connection to concatenation, that's kind of its own thing.
