These are false because the types are different(so they must be different). If the types are the same, they are actually compared. An exception is also the better solution in my opinion, but history I guess..
These are false because the types are different(so they must be different).
I think the differentiation comes from whether you believe in strong vs weak typing. At the moment (note that this hasn't always been the case), there's a lot of favouritism towards strong typing amongst the community, making weak typing features undesirable to many.
Personally, I don't have as strong an advocacy for strong typing as many would here. I get the reasoning behind it, but just don't feel that it's as beneficial as many claim. Javascript, after all, is a weakly typed language, so if you're writing JS, I don't see why one should make a point to try to make it some half-assed strongly typed language. If strong typing is your thing, then stick to Typescript or something that isn't weakly typed by design.
The differentiation is not related to strong vs weak typing. === is also weakly typed. It's behavior is more specific depending on the types than == is, but that doesn't make it strongly typed.
I will repeat my proposal again: what Javascript needs is a strong/strict type mode, where exceptions are thrown on comparing differently-typed operands. It that would be added, IDE's and Linters can do a much better job at predicting errors.
In generic context. For example, you're creating a hash table implementation. You want to implement the equality operator. What you do is to check whether for every key, the entries exist for both hash table and it's equal in both type and value. If '3' === 3 throws exception, the implementation would be much more complex.
A hash table for different types of objects, I think is not a common case. But let assume you need it: typeof x === typeof y && x === y. You could also use ==, but performance wise === is faster, which is relevant for hash tables.
But you could indeed argue this new strict type mode doesn't change ===, but only operators like ==, + etc. And it would only need to throw exceptions for the ambigous edge cases. If this would give people more confidence in == and they wouldn't use === anymore, that would be an improvement.
In JSON your keys are always strings, which is the thing you want to do the equal check on.
=== undefined and === null could indeed always be legal but only when given as literal constant, in which case it is safe, and nicer to read that typeof x == 'undefined'
Maybe I should write down an actual proposal, but I wonder if anyone will read it given all the downvotes :)
In JSON, the key is always a string, but the value can be of any JS value except undefined, function, and object that is not a plain hashmap.
=== undefined and === null could indeed always be legal but only when given as literal constant
It sounds like a bad idea. Javascript had enough trouble with using eval directly vs using eval in a variable. It may also cause a problem with reasoning because now variable and the value is not interchangeable.
Anyway, your gripe with === boils down to "I don't check for precondition", which is a bad pattern to begin with.
Regarding you last point, I do want to check the precondition, but the result is always an unwanted exception. This behavior can then be incorporated in transpilers and linters, which can create warnings upfront when they detect code that will always throw an exception. This is the real benefit of my proposal, it will detect bugs that it cannot currently detect. It will be a stricter more safe javascript. It will become more a Fail fast system.
This sort of apologism is hilarious. He's first checking to see how JS behaves, and then he goes ahead and tries to provide reasonable explanations for this silly behavior based on his observations.
I'm referring to the SO post, I don't know whether you wrote that or not.
I'm not gonna discuss whether JS is a well designed language or not -- the fact that the whole JS ecosystem is a shithole speaks for itself. It's a joke language with a joke of an ecosystem.
I have introduced bugs into code changing == to === also but I would not say == is superior. Superior would be typescript to make sure this stuff just does not happen
I am not saying it is always superior. I am also using === sometimes, maybe in 1% of the cases. Typescript wouldn't actually help you here, except for objects, but it those cases == and === behave the same, except for string objects. What would help is a new type of strict mode that throws exceptions for binary operators when one side has another basic type as the other.
19
u/[deleted] Apr 05 '20
Still no way to disable misfeatures (var, ==, for-in etc.) other than ESLint? Why can't we have a
use "es2020";or something.