Another point: The main argument for using strict equality is because it does type conversions which can cause bugs. Since we are using a strongly typed language, type safety is generally enforced by the compiler, so most of those bugs are not relevant to us. Therefore the class of bugs that come from using strict equality is probably worse and we should prefer regular equality.
> On Jun 22, 2017, at 9:45 AM, Harbs <harbs.li...@gmail.com> wrote: > > I’m not going to invest a lot more time into this. > > You willy-nilly changed equality to strict equality. That cost me time and > money. I vetoed your change. Period. > > Changing all equality to strict equality is (IMO) pedantic. In most cases the > two operators are functionally equivalent. In some cases strict equality is > necessary. In some cases equality is necessary. > > Performance gains are NOT significant. Performance gains by using strict > equality is in microseconds (at most). They are not measurable in real > applications. If you end up doing a type conversion to use the strict > equality, all performance gains are lost. This topic has been discussed to > death on other places on the web. Strict equality comes at a cost of an extra > byte in the download. In my book, that’s a wash. > > If I broke something by reverting your changes, feel free to fix it again, > but I will veto any change to use strict equality against null unless there > is a very strong argument to do so in a specific case. > > Thanks, > Harbs > >> On Jun 22, 2017, at 2:03 AM, Justin Mclean <jus...@classsoftware.com> wrote: >> >> Hi, >> >>> It broke when element was undefined. >> >> So why not only change / revert that? >> >>> There’s no reason to use strict equality so rampantly. (The performance >>> gains are insignificant.) >> >> As has previously been discussed on develop the performance gains are >> significant. >> >> Thanks, >> Justin >
