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

Erik Reppen erik.reppen at gmail.com
Thu Aug 16 06:58:09 PDT 2012


@Rick Bah, mailing-lists. Sorry about the dupe e-mail. I forgot to reply to
all.

I absolutely agree with not permanently altering existing core library
methods if you can avoid it. I guess I was thinking more of jQuery's
adapter/decorator approach vs the somewhat more extreme (IMO) step of
down-compiling to a functional language that lets you alter property
context at will. Although of course for stuff like arrow funcs today rather
than tomorrow, that's the only option you have and being something of a
perpetually recovering curmudgeon/purist I haven't given coffee a fair
shake yet.

You could also take a pocket dimension approach where you swap out
prototypes in a re-usable function that sets things more to your liking and
then cleans up after itself.

myPocketD( function(){ //altered proto methods swapped before this func arg
is fired and then swapped back after it closes
    [0,1].join(''); //alerts 'Somebody did something awful to the Array
join method!'
    //you could pretty much write your entire app in spaces like this and
then plug in third party stuff without fear of blowing anything up.
});

[0,1].join(''); //returns '01' as expected

On Thu, Aug 16, 2012 at 7:44 AM, Rick Waldron <waldron.rick at gmail.com>wrote:

>
>
> On Thursday, August 16, 2012 at 5:24 AM, Andreas Rossberg 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.
>
> Rereading my initial response now and it's not clear that i meant that
> changing APIs to return different value would be worse. So yes, I agree
> with your correction and I apologize for being unclear.
>
> Rick
>
>
>
> 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/50cbaec9/attachment.html>


More information about the es-discuss mailing list