Accepting an array as the first parameter to String.prototype.includes

Garrett Smith dhtmlkitchen at gmail.com
Wed Mar 11 03:55:00 UTC 2015


On 3/10/15, Edwin Reynoso <eorroe at gmail.com> wrote:

Hi Edwin -

> Well the current ES6 `.includes()` was before named `.contains()`:
> [String.prototype.includes] (
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/includes#String.prototype.contains
> )
>
> But if Garrett Smith was trying to point out that `.contains()` would be
> better naming for the specific purpose of using an Array:
> `str.contains(["Mary", "Bob"])` then ok? maybe.
>

str.contains was Andrea's interpretation of my example. Nevermind
that; let me try again...

You first asked about making String.prototype.includes take an array,
check every item in the array, and return false if any array item is
not present in the string, else return true. From that, you switched
it around to array.every, to make sure every item was in the string.

 names.every(name => str.includes(name));

So far so good...

That's essentially what Array.prototype.containsAll would do.

Array.prototype.containsAll(anotherArray)

You can split the string to get anotherArray.

names.every(str.split(/,\s*/));

I cannot explain what ES6 @@split does. The spec have gotten even
farther away from how web developers understand the language.

The ECMAScript specification has always been complicated by internal
specification mechanisms, and it was because of this obfuscation that
I was able to have a bit of an edge on others. I was able to
understand the difference between the confusingly same-named
[[Prototype]] (an object's internal property) and fn.prototype (the
property that every user-defined function gets by default), and that
there implies that each user-defined function has both a [[Prototype]]
(being Function.prototype) and a .prototype property. It's confusing,
but I got it.

The new stuff in the spec, where there is not even
String.prototype.split, but @@split is hard to understand. The
ECMAScript 3 spec was already too hard for most developers. Things
like missing RegularExpressionLiteral, the
ActivationObject/VariableObject (which one is it?), PrimitiveValue
being a number for Date objects, but where addition calls ToPrimitive
with hint "string", and that gets passed to DefaultValue. It's hard.
We need to work for the tech companies that steal your data and
provide useless junk to the user. Call us rockstars or other insulting
titles, but at the end of the day, I need to to is memorize those
specs if I want to understand what I am doing in order to pay my rent.
It can and should suck less.

ECMAScript 5 added complexity. ECMAScript 6's explanations and
specification terminology seems too much for me. The spec shouldn't be
so hard that programmers can't understand it. A good spec should serve
as a reference for developers to go and look up how it works.

I can't say how I'd write it better because I haven't taken the time
to grok it all. Nor do I plan to - life is too short.
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io
personx.tumblr.com


More information about the es-discuss mailing list