Array.prototype.contains

Rick Waldron waldron.rick at gmail.com
Sat Nov 3 12:51:26 PDT 2012


On Fri, Nov 2, 2012 at 9:55 PM, Axel Rauschmayer <axel at rauschma.de> wrote:

> +1
>
> I have always found Java’s collection API fairly intuitive. It could serve
> as a role model, at least partially.
> - Map: containsKey, containsValue
>

I'd rather see Set.prototype.values() defined for Map.prototype


> - Set: contains
>





>
> Note that it has an isEmpty() method.
>

.size get-accessor property, which will be 0 if it's empty. I honestly
believe in api growth should address a need, if this turns out to be a pain
point, then we should consider it for Collection extras in ES7, but I've
_never_ seen anyone extend Array.prototype with an isEmpty method. There
are user land implementations of isEmpty() and isEmptyObject() that are
used to make up for Object.prototype not having any way of determining if
there are any own-enumerable properties.

var o = {};

isEmpty(o); // true

o.p = 1;

isEmpty(o); // false

but Map and Set shouldn't need anything like this, because like Array, they
have a mechanism for disclosing "how many things I have"



> I would also want to have its methods for combining collections such as
> removeAll() and retainAll().
>

A more generic .filter() method would allow user code to create these
methods if the need was sufficient.

Rick



>
> http://docs.oracle.com/javase/6/docs/api/java/util/Map.html
> http://docs.oracle.com/javase/6/docs/api/java/util/Set.html
>
>
> [[[Sent from a mobile device. Please forgive brevity and typos.]]]
>
> Dr. Axel Rauschmayer
> axel at rauschma.de
> Home: http://rauschma.de
> Blog: http://2ality.com
>
> On 02.11.2012, at 22:30, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>
>
> On Nov 2, 2012, at 10:56 AM, Jason Orendorff wrote:
>
> On Fri, Nov 2, 2012 at 12:29 PM, Domenic Denicola <
> domenic at domenicdenicola.com> wrote:
>
>> > If we call it "has", should we also rename String.prototype.contains?
>>
>> I'd say no; the distinction between collections "having" an element and
>> strings "containing" a substring seems very sensible. It's a bit more
>> awkward to say a string "has" a substring, and a string is definitely not a
>> collection of substrings in any reasonable sense.
>>
>
> Well, you could also note that array.has(x) looks for a particular value,
> while map.has(x) looks for a particular key.
>
> But that's not the point. There's no common formal contract implemented by
> all these methods; what they share is an informal "hey, look in this thing,
> and tell me if you see that thing" vibe.
>
>
> There is no verifiable formal contract.  But there can be an informal
> contract.  In my experience, it is very important when using a dynamic
> language to recognize and try to support such informal contracts.
>
> All the uses of "has" we have defined so far are about the "keys".  Having
> one place that is about the "values" to create unnecessary confusion
>
> Note that we (the JS/ES designers) already have a history of being being
> inconsistent in our use of names.  Consider String indexOf and Array
> indexOf they are named the same and appear to have signatures.  But they
> logically are doing quite different things.  String indexOf is looking for
> the index of the first element of a subsequence of character elements that
> matches a specific character sequence.  Array indexOf is looking for the
> index of a single element that contains a specific value.  You might want
> to implement a logically similar subsequence search for Array's but if you
> do, you can't call it indexOf because that name was already used for
> something with different semantics.  We should try to do better as people
> for our example.
>
> Allen
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121103/51d19cbc/attachment.html>


More information about the es-discuss mailing list