Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Operator for comparison with type coercion #1693
I'm quite new to coffescript and maybe this has been up for discussion before, but I couldn't find anything related.
Now, in some rare cases, I find my self wanting to use the double equal (
I know that you can solve the number comparision problem by using
This is a duplicate of at least a couple previous tickets, although my github search skills are failing me at the moment.
We don't want to have
In the one place where it's truly useful in JS, you can use the existential operator instead:
... checks if
If you want to compare numbers as strings, convert them to strings ... and if you want to compare strings as numbers, parse them as numbers.
For some broken
Thanks for a good answer, I figured that this question ought to be a dupe =)
I understand your point from a readability perspective: by doing the casting yourself, you tell the world that you think you know what you're doing. But from a number parsing perspective I don't see why
Jeremy, this is one of the things where Coffeescript adds annoying behavior to JS instead of taking it away. 8 == '8' is the common case, the principle of least surprise; what Coffeescript does with replacing == with === is made developers exchange this:
Wallin's suggestion of an ~= comparison would at least cut down on all the extraneous
@whatcould: I'm afraid we'll have to disagree about that.
... and your
Just throwing my voice in here:
Without any coercive operator, it's impossible for me to take both boxed-natives and unboxed-natives to the same function without an unnaturally quantity of boilerplate for every argument that may be boxed:
… and then that becomes even more ugly, complex, and fragile, if I'm accepting multiple types of primitive for a given argument (say, a string or an integer.)
Not saying that this alone is enough reason to bring a
referenced this issue
Aug 18, 2013
I know the decision's already been made here, but I love an opt-in solution for this that allows us to use coercion when we intend for it to happen. I see valid use cases for this outside of
Maybe if an ugly and rough-sounding enough work was picked, the intent would be clear and bugs would be avoided. I thought about it overnight and landed on
It's not ungainly to convert a string to a number (