<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Javascript &#8216;==&#8217; operator and indexOf failure</title>
	<atom:link href="http://www.jasonclawson.com/2008/07/01/javascript-operator-and-indexof-failure/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jasonclawson.com/2008/07/01/javascript-operator-and-indexof-failure/</link>
	<description>Advanced Web Development Blog</description>
	<pubDate>Wed, 08 Sep 2010 03:39:26 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Rob</title>
		<link>http://www.jasonclawson.com/2008/07/01/javascript-operator-and-indexof-failure/#comment-42</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Wed, 08 Apr 2009 16:16:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonclawson.com/?p=48#comment-42</guid>
		<description>Type coercion seems to be Bad, at least as far as Douglas Crockford is concerned. Check out http://www.jslint.com/lint.html (scroll down to "== and !=").</description>
		<content:encoded><![CDATA[<p>Type coercion seems to be Bad, at least as far as Douglas Crockford is concerned. Check out <a href="http://www.jslint.com/lint.html" rel="nofollow">http://www.jslint.com/lint.html</a> (scroll down to &#8220;== and !=&#8221;).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Radomir</title>
		<link>http://www.jasonclawson.com/2008/07/01/javascript-operator-and-indexof-failure/#comment-39</link>
		<dc:creator>Radomir</dc:creator>
		<pubDate>Sun, 01 Mar 2009 22:00:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonclawson.com/?p=48#comment-39</guid>
		<description>wasn't there a new release for this?</description>
		<content:encoded><![CDATA[<p>wasn&#8217;t there a new release for this?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>http://www.jasonclawson.com/2008/07/01/javascript-operator-and-indexof-failure/#comment-30</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Sat, 26 Jul 2008 15:43:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonclawson.com/?p=48#comment-30</guid>
		<description>Yeah I know... this bug is really pervasive across libraries and no one really notices!  Here is the link to the bug report for ExtJS:  http://extjs.com/forum/showthread.php?t=40040</description>
		<content:encoded><![CDATA[<p>Yeah I know&#8230; this bug is really pervasive across libraries and no one really notices!  Here is the link to the bug report for ExtJS:  <a href="http://extjs.com/forum/showthread.php?t=40040" rel="nofollow">http://extjs.com/forum/showthread.php?t=40040</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Juan Mendes</title>
		<link>http://www.jasonclawson.com/2008/07/01/javascript-operator-and-indexof-failure/#comment-29</link>
		<dc:creator>Juan Mendes</dc:creator>
		<pubDate>Wed, 23 Jul 2008 16:17:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonclawson.com/?p=48#comment-29</guid>
		<description>Point taken. I would have figured prototype, ext-js and jquery would know better than to use double equals for an equality test in a very generic function.</description>
		<content:encoded><![CDATA[<p>Point taken. I would have figured prototype, ext-js and jquery would know better than to use double equals for an equality test in a very generic function.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>http://www.jasonclawson.com/2008/07/01/javascript-operator-and-indexof-failure/#comment-28</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Wed, 23 Jul 2008 13:11:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonclawson.com/?p=48#comment-28</guid>
		<description>&lt;p&gt;To say that == functionality is a bug I suppose can be considered incorrect only by the fact that this functionality is documented.  But you hit on my point exactly; it's not how most programmers expect it to behave.  Good programming languages should be predictable and useful in the way they behave.&lt;/p&gt;
&lt;p&gt;You also said you take care to always use '===' in most cases.  '===' is hardly the de facto standard equality comparison operator.  Just by the fact that you have to consciously make a decision to use the triple equals to "avoid problems like [this]" indicates an inherent problem with the '==' implementation.  Simply put, it doesn't do what you want nor expect.  I call that a bug.&lt;/p&gt;
&lt;p&gt;The conversion of types functionality is not particularly useful in so far as comparing objects or functions to primitive types and strings.  The only use for type conversion is in comparing a number to a string that contains a number:  6.2 == "6.2" Therefore, I consider this a bug.  Most, if not all other scripting languages, convert between primitives but do type checking for objects.&lt;/p&gt;
&lt;p&gt;Further supporting this as a bug is that no other language (to my knowledge... please correct me if I am wrong and I very well could be since I have not used every scripting language ;-)) behaves this way except for ECMA script.&lt;/p&gt;
&lt;p&gt;To suggest that this is common knowledge is definitely incorrect since every major javascript library currently implements indexOf using '==' instead of '===' which is incorrect.&lt;/p&gt;
&lt;p&gt;I am glad that you use '===' and that you are aware of the pitfalls of '=='.  However, I would venture to guess that 90% of developers out there do not know this and do not have any idea that the libraries they are using implement indexOf incorrectly.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>To say that == functionality is a bug I suppose can be considered incorrect only by the fact that this functionality is documented.  But you hit on my point exactly; it&#8217;s not how most programmers expect it to behave.  Good programming languages should be predictable and useful in the way they behave.</p>
<p>You also said you take care to always use &#8216;===&#8217; in most cases.  &#8216;===&#8217; is hardly the de facto standard equality comparison operator.  Just by the fact that you have to consciously make a decision to use the triple equals to &#8220;avoid problems like [this]&#8221; indicates an inherent problem with the &#8216;==&#8217; implementation.  Simply put, it doesn&#8217;t do what you want nor expect.  I call that a bug.</p>
<p>The conversion of types functionality is not particularly useful in so far as comparing objects or functions to primitive types and strings.  The only use for type conversion is in comparing a number to a string that contains a number:  6.2 == &#8220;6.2&#8243; Therefore, I consider this a bug.  Most, if not all other scripting languages, convert between primitives but do type checking for objects.</p>
<p>Further supporting this as a bug is that no other language (to my knowledge&#8230; please correct me if I am wrong and I very well could be since I have not used every scripting language ;-)) behaves this way except for ECMA script.</p>
<p>To suggest that this is common knowledge is definitely incorrect since every major javascript library currently implements indexOf using &#8216;==&#8217; instead of &#8216;===&#8217; which is incorrect.</p>
<p>I am glad that you use &#8216;===&#8217; and that you are aware of the pitfalls of &#8216;==&#8217;.  However, I would venture to guess that 90% of developers out there do not know this and do not have any idea that the libraries they are using implement indexOf incorrectly.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Juan Mendes</title>
		<link>http://www.jasonclawson.com/2008/07/01/javascript-operator-and-indexof-failure/#comment-27</link>
		<dc:creator>Juan Mendes</dc:creator>
		<pubDate>Tue, 22 Jul 2008 22:33:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonclawson.com/?p=48#comment-27</guid>
		<description>I think calling your problem with the equals operator a bug is not accurate, even though that behavior is probably not what most programmers intended. The double equals operator is known to convert objects to strings when comparing them to other strings. We at workforce software have come to use strict equality in most cases to avoid problems like that.</description>
		<content:encoded><![CDATA[<p>I think calling your problem with the equals operator a bug is not accurate, even though that behavior is probably not what most programmers intended. The double equals operator is known to convert objects to strings when comparing them to other strings. We at workforce software have come to use strict equality in most cases to avoid problems like that.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
