Well, I was thinking !== null for most tests I guess but I could see potential for typeof in the simpler methods that return other stuff.<div><br></div><div>So by this standard would:<br><br>'squirrel'.match(/wombat/);<div>
<br></div><div>be better if it returned an empty array rather than null? If that's the case, then I guess I wanted to clear the forest for the sake of a few missing trees.</div><div><br></div><div>In what cases does a null-returning method make sense from a language-design-perspective? Or is null also a side-effect of not having try/catch from the start?</div>
<div><br></div><div><br></div><div><div class="gmail_quote">On Thu, Aug 16, 2012 at 4:47 PM, Brendan Eich <span dir="ltr"><<a href="mailto:brendan@mozilla.org" target="_blank">brendan@mozilla.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Andreas Rossberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 16 August 2012 00:35, Rick Waldron<<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a><u></u>>  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen<<a href="mailto:erik.reppen@gmail.com" target="_blank">erik.reppen@gmail.com</a>>  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This topic has probably been beaten to death years before I was even aware<br>
of es-discuss but it continues to get mentioned occasionally as a point of<br>
pain so I thought I'd see if I couldn't attempt to hatch a conversation and<br>
maybe understand the design concerns better than I likely do now.<br>
<br>
<br>
Consistent Type Return for Pass and Fail?<br>
<br>
The principle of consistent type-return has occasionally skewered me as<br>
somebody who came to non-amateur levels of understanding code primarily<br>
through JavaScript. I can see the value in maintaining consistent types for<br>
positive results but not so much for indicators that you didn't get anything<br>
useful. For instance:<br>
<br>
* [0,1].indexOf('wombat'); //returns an index on success or  -1 to<br>
indicate failure. -1 passed on to a lot of other array methods of course,<br>
indicates the last element. If you'd asked me the day I made that mistake I<br>
could have told you indexOf probably returns -1 on failure to find something<br>
but it didn't occur to me in the moment.<br>
</blockquote>
It would be far worse to have a different type of value as a return, right?<br>
</blockquote>
<br>
Actually, no. It is far better to have something that produces failure<br>
as immediately and as reliably as possible when used improperly.<br>
Sentinel values are a prominent anti-pattern.<br>
</blockquote>
<br></div></div>
Spoken like a true ML'er :-P. Also, you mention failure and it's true that lack of try/catch in original-JS and ES1&2 meant APIs had to overload return values with out-of-band failure codes.<br>
<br>
However, JS hackers do not write refutable match expressions cracking return value using typeof or better. *That* is the anti-pattern here.<br>
<br>
-1 as an out-of-band (for non-negative indexes) return code is actually easier to test and works well with certain code patterns, compared to a differently typed code. JS is not alone here, tons of precedent even in other dynamic languages that do have try/catch and even matching.<br>

<br>
The issue is "failure". Sometimes not finding the wanted character index is not failure but just a condition to test that leads to an alternative strategem. Then the conciseness and clarity of the test matters, and typeof rv != "number"is the wrong tool compared to rv < 0.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, I agree that there is no chance of fixing that for existing libraries.<br>
</blockquote>
<br></div>
That's another thing. Deviating from existing patterns for new APIs that have similar names and motivations is going to be a pain for some users. It's not obvious to me that we have a real "failure must be prompt" problem here that justifies breaking with convention.<span class="HOEnZb"><font color="#888888"><br>

<br>
/be<br>
</font></span></blockquote></div><br></div></div>