Consistency in The Negative Result Values Through Expansion of null's Role

Erik Reppen erik.reppen at
Fri Aug 17 08:43:05 PDT 2012

I think at this time I would definitely favor consistent negative returns
in a higher-level user-defined library or framework where the nuts and
bolts type-stuff is dealt with for you, but I think I can see the point of
not going that route for the core language API. Or at least in any case,
I'm confident I can't really make an informed argument/decision until I
fill in some of these hedge-mage developer knowledge gaps in regards to the
likely usage-scenarios/patterns/formal-comp-sci-training-"duh"-algorithms
being considered for the return values that puzzle me.

Thanks all for the thoughtful replies. It definitely gave me some food for
thought and new targets to hit on the self-improvement list.

On Fri, Aug 17, 2012 at 9:18 AM, Brendan Eich <brendan at> wrote:

> Erik Reppen wrote:
>> 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.
>> So by this standard would:
>> 'squirrel'.match(/wombat/);
>> be better if it returned an empty array rather than null?
> Probably not. Again, the main consideration is usability. If you want to
> catch mismatch -- and regexp matchers do, often -- then with an empty array
> on mismatch, you'd have to write
>   var m = r. match(s);
>   if (m.length == 0) { /* mismatch handling here */ }
> or trickier equivalents, but not
>   if (!m) { /* mismatch handling here */ }
> While empty array does convert to empty string, the match array in general
> is not used as a concatenation part. Any captured groups would add extra
> elements to the array, and a /g flag would make all the matches pop out.
> The "blind concatenation" use-case isn't there, in my experience.
> Experience is what drivers good API design, namely user experience and
> usability. Most match users want to know about mismatch and handle it.
> Whether mismatch is "failure" or "fallback", it's a fork in the program's
> control flow, most of the time.
> This is much less so the case with charAt.
>  If that's the case, then I guess I wanted to clear the forest for the
>> sake of a few missing trees.
> Systematizing a-priori based on a theory of failure or a one-true OOB
> return value is probably a mistake. Sometimes -1 works, other times "", yet
> others null or even a thrown exception. The design depends on the
> particulars. Channel Aristotle, not Plato.
>  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?
> Null has its uses. If you think of undefined as "no value" and null as "no
> object" and use undefined for any-value-returning methods, and null for
> maybe-object returning methods, you won't go too wrong.
> /be
>> On Thu, Aug 16, 2012 at 4:47 PM, Brendan Eich <brendan at<mailto:
>> brendan at>> wrote:
>>     Andreas Rossberg wrote:
>>         On 16 August 2012 00:35, Rick Waldron<waldron.rick at
>>         <mailto:waldron.rick at**>>  wrote:
>>             On Wed, Aug 15, 2012 at 6:02 PM, Erik
>>             Reppen<erik.reppen at
>>             <mailto:erik.reppen at>**>  wrote:
>>                 This topic has probably been beaten to death years
>>                 before I was even aware
>>                 of es-discuss but it continues to get mentioned
>>                 occasionally as a point of
>>                 pain so I thought I'd see if I couldn't attempt to
>>                 hatch a conversation and
>>                 maybe understand the design concerns better than I
>>                 likely do now.
>>                 Consistent Type Return for Pass and Fail?
>>                 The principle of consistent type-return has
>>                 occasionally skewered me as
>>                 somebody who came to non-amateur levels of
>>                 understanding code primarily
>>                 through JavaScript. I can see the value in maintaining
>>                 consistent types for
>>                 positive results but not so much for indicators that
>>                 you didn't get anything
>>                 useful. For instance:
>>                 * [0,1].indexOf('wombat'); //returns an index on
>>                 success or  -1 to
>>                 indicate failure. -1 passed on to a lot of other array
>>                 methods of course,
>>                 indicates the last element. If you'd asked me the day
>>                 I made that mistake I
>>                 could have told you indexOf probably returns -1 on
>>                 failure to find something
>>                 but it didn't occur to me in the moment.
>>             It would be far worse to have a different type of value as
>>             a return, right?
>>         Actually, no. It is far better to have something that produces
>>         failure
>>         as immediately and as reliably as possible when used improperly.
>>         Sentinel values are a prominent anti-pattern.
>>     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.
>>     However, JS hackers do not write refutable match expressions
>>     cracking return value using typeof or better. *That* is the
>>     anti-pattern here.
>>     -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.
>>     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.
>>         However, I agree that there is no chance of fixing that for
>>         existing libraries.
>>     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.
>>     /be
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list