{"id":609,"date":"2015-09-19T15:10:06","date_gmt":"2015-09-19T22:10:06","guid":{"rendered":"http:\/\/kagan.mactane.org\/blog\/?p=609"},"modified":"2015-12-07T19:58:54","modified_gmt":"2015-12-08T03:58:54","slug":"skipping-regexes-in-es6-is-nothing-compared-to-skipping-boolean-comparison-warts","status":"publish","type":"post","link":"https:\/\/kagan.mactane.org\/blog\/2015\/09\/19\/skipping-regexes-in-es6-is-nothing-compared-to-skipping-boolean-comparison-warts\/","title":{"rendered":"Skipping Regexes in ES6 is Nothing Compared to Skipping Boolean-Comparison Warts"},"content":{"rendered":"

Yesterday, Wes Bos tweeted about<\/a> ES6’s startsWith()<\/code>, endsWith()<\/code>, and includes()<\/code> methods. He said it was “[t]hree less JavaScript Regexes you’ll have to write”.<\/p>\n

Which is true, but I feel it misses the point. I mean, the regexes for initial match and final match are really not that hard, and the regex for plain inclusion is, well, basically the bare form of any regex: put slashes around it, and you’re done.<\/p>\n

The coolest thing about these new methods isn’t the ability to change \/^foo\/<\/code>, \/foo$\/<\/code>, or \/foo\/<\/code> into just plain foo<\/code>. That’s a savings of at most three keystrokes, and fairly little cognitive load. No, the coolest thing about these is not having to add != -1<\/code> at the end of them!<\/strong><\/p>\n

I think looking at it as “not having to write regexes” is really missing the point. In fact, I’m going to dust off something I wrote on a private Livejournal, back in 2007:<\/p>\n

<\/div>\n

When doing regex matches on strings, I’m sick and tired of writing things like:<\/p>\n

if (some_string.search(\/some_regex\/) != -1<\/strong>) {<\/div>\n

In particular, it’s the bold part I object to. And for what it’s worth, there’s a similar wart in PHP, where searching for a substring requires the construct:<\/p>\n

if (false ===<\/strong> strpos($haystack, $needle)) {<\/div>\n

In both of these languages, the problem is that the function or method that’s doing the searching isn’t returning a strict Boolean, but it is<\/em> being evaluated in a Boolean context. PHP’s strpos()<\/code> returns the position at which the needle starts in the haystack string (which may be zero if the needle is right at the beginning of the haystack), or FALSE if the needle isn’t there. JavaScript’s string.search()<\/code> method similarly returns the position at which the matched text starts (which, again, may be zero), or -1 on failure.<\/p>\n

And both of these languages evaluate zero as false in a Boolean context, so that you can find the text you’re looking for (right at the beginning of your string) and have the if<\/code> statement claim it’s not there.<\/p>\n

Perl avoids this entire problem by simply making a binding to a pattern match return Boolean, and not bother giving you the position. (To be honest, you hardly ever need the actual position.) And maybe I’ve been spoiled by years of writing things like:<\/p>\n

if ($some_string =~ \/some_regex\/) {<\/div>\n

…but, honestly, I think Perl is getting it right and the other two are getting it wrong.<\/p>\n

<\/div>\n

So that’s what I wrote back in 2007. At that time, of course, PHP and Perl were both more significant; I wouldn’t mention them nearly as much today. Which is a bit of a shame, because the analysis of how too much information makes life harder<\/em> is still apropos, and Perl still gets it right in a way that various other languages don’t.<\/p>\n

The ES6 methods help fix that, because they just return Boolean<\/strong>, instead of getting all fancy-pants and giving you the position where the match was found. (In fact, back in 2007, when everyone was using Prototype.js and the idea of messing with built-in objects’ prototypes wasn’t as unfashionable as it is now, I pondered adding a function called “contains” to the String prototype in my company’s standard JavaScript library. And check it out; Firefox and Chrome have a String.includes()<\/code> method<\/a>, which used to be named contains()<\/code> at least in Firefox.<\/p>\n

But they still only take a case-sensitive string to search for, not a regex. Which makes me sad.<\/p>\n","protected":false},"excerpt":{"rendered":"

Yesterday, Wes Bos tweeted about ES6’s startsWith(), endsWith(), and includes() methods. He said it was “[t]hree less JavaScript Regexes you’ll have to write”. Which is true, but I feel it misses the point. I mean, the regexes for initial match and final match are really not that hard, and the regex for plain inclusion is, well, […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[7,146,83,70,60,33,71],"_links":{"self":[{"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/posts\/609"}],"collection":[{"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/comments?post=609"}],"version-history":[{"count":3,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/posts\/609\/revisions"}],"predecessor-version":[{"id":659,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/posts\/609\/revisions\/659"}],"wp:attachment":[{"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/media?parent=609"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/categories?post=609"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/kagan.mactane.org\/blog\/wp-json\/wp\/v2\/tags?post=609"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}