2

I mean it as it is used in JavaScript. Just curious why this is not supported in more languages? Like Java for example does not have it? Seems to be a very useful operator to have.

5
  • 13
    Java is a statically typed language, therefore there is no need to check based on type because Java always knows the type at compile time. JavaScript has dynamic typing, thus it is not always known what type an object is in advance, thus the extra operator.
    – riwalk
    May 26, 2011 at 20:22
  • 33
    JavaScript's === is just there because == has annoying, counter-intuitive behavior. Languages that don't have a broken == don't need to fix it with a ===. May 26, 2011 at 21:18
  • 1
    @ReinHenrichs - == in JavaScript (or PHP) is not 'broken' - it's just that the dynamic/loose typing allows for 0 == '0'.
    – HorusKol
    May 27, 2011 at 1:21
  • 22
    Yes, I understand the behavior. I just think it's terrible. May 27, 2011 at 1:49
  • 2
    Obvious answer: Because in most languages, == means what === means in Javascript.
    – user16764
    Apr 23, 2013 at 18:02

2 Answers 2

18

Javascript's and PHP's "regular" == operator does implicit conversions. === exists so you can omit these coercions when you don't need them or don't want them to apply. In many other languages, including dynamic ones (e.g. Python), implicit conversions are vastly less frequent. That is, integers may be converted to floats when doing math or comparing, but "1" won't go along with 1. In those languages, the == operator is basically the equivalent of looser language's ===.

To pick up the example, Java goes even further - its == will only consider two expressions equal if the evaluate to exactly the same reference, i.e. are the same objects (primitive types are, as usual, an exception). You can't get any stricter. What should a === do, consider two references equal only if they resulted from the same expressions? ;-)

4
  • 2
    In C#, it would have been useful to have separate value equality and reference equality operators, rather than having an "==" operator whose behavior sometimes mirrors that of the effectively-virtual Object.Equals and sometimes mirrors that of the non-virtual Object.ReferenceEquals. Consider, for example, given function bool Eq<T>(T p1,T p2) where T:class {return p1==p2;}, what is the effect of bool StrEq(string p1, string p2) {return Eq<string>(p1,p2);}. If the latter function called Eq<object>(p1,p2) it should be expected to use reference equality, but...
    – supercat
    Jul 19, 2012 at 15:35
  • ...it will still use reference equality even if it calls Eq<string>(p1,p2), even though the operands to == would appear to be of type string.
    – supercat
    Jul 19, 2012 at 15:37
  • @supercat That's interesting and ugly, and yes, separate operators for value and reference equality is a good idea. But it's not really related to the question, isn't it? I'm not complaining, I just want to be clear about this.
    – user7043
    Jul 20, 2012 at 15:43
  • I was reading the question as asking fundamentally why more languages don't have more than one type of equality-comparison operator; your answer seemed to question why such a thing would be needed in Java. Having an extra operator would be most helpful if code could use it for those types, and only those types, which explicitly define it (the way the = operator works in vb.net, btw). Perhaps Java could have defined a valueEquatable interface, and had one of its equality operators only act on primive value types or types which implement valueEquatable?
    – supercat
    Jul 20, 2012 at 16:05
5

In JavaScript == uses type coercion for evaluating equality.

0 == false //=> true
1 == true  //=> true
null == undefined //=> true

Using === eliminates type coercion, acting as you would expect the operator to act. If the types are the same and the values are the same it returns true, otherwise false.

Other languages that do not utilize type coercion for equality checks don't need a === because that functionality is standard.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.