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

Erik Reppen erik.reppen at gmail.com
Thu Aug 16 08:25:39 PDT 2012


Yeah, I could've been more clear. I didn't expect anybody to rewrite JS in
two weeks and the vendors to implement a dual-interpreter that would patch
things up with a new 'use erik.preferences'; statement (although if all
relevant parties were to offer... I have a birthday next year, that's all
I'm saying), but I do wonder if there's some value to these various fail
values that could be beneficial if implemented more consistently with new
methods moving forward. Or at the very least make null the JS international
word for 'nope.'

But why do people consider sentinel values anti-patterns? I've seen some
disagreement over this here and there (mostly on stackOverflow) and cursory
googling before work hasn't been enough to find good articles on the
subject. Wouldn't that be more of a language-specific concern than a
general anti-pattern? I haven't spent much time writing anything in an
explicit return-type/param-type-declared language but I can see how it
would be obnoxious in any paradigm closer to that.

I would think you would either always want to send the same fail signal
consistent with the return-context and type of positive return values in a
strictly typed languages (e.g. anything returning integers representing
array inexes always gives you -1 for fail) or have a universal signal for
failure in a more dynamic language like JS. I understand how handing off a
variety of types for success could get ugly or be seen as unpredictable in
even a more dynamic language but being able to more predictably detect a
negative result strikes me as useful for not having to research and write
different checks on a per-method basis for somebody who is new to the
language or a bit dizzy occasionally like myself.

It's enough of a concern to me that I'd probably consider wrapping every
type in my own factories to write adapting methods with more predictable
returns if I were working on a fairly extensive library or framework
project.


On Thu, Aug 16, 2012 at 4:24 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 16 August 2012 00:35, Rick Waldron <waldron.rick at gmail.com> wrote:
> > On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen <erik.reppen at gmail.com>
> 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.
>
> However, I agree that there is no chance of fixing that for existing
> libraries.
>
> /Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120816/f3ca337b/attachment-0001.html>


More information about the es-discuss mailing list