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 <[email protected]>wrote: > On 16 August 2012 00:35, Rick Waldron <[email protected]> wrote: > > On Wed, Aug 15, 2012 at 6:02 PM, Erik Reppen <[email protected]> > 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
