On Nov 2, 2012, at 4:54 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> ... >> 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 > > http://stackoverflow.com/questions/4962361/where-is-javas-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. > > That one never bugged me, and I suppose one could "fix" it by allowing > by-value search for a sub-array from Array.prototype.indexOf. I've never seen > anyone do that.
It never bothered me either up to now. Probably because we usually don't think about JS strings as a "collections" (immutable array of uint16s) all that much. But if you starting thinking about strings as a kind of collection and look for uniformity in collection interfaces, indexOf stands out as being problematic. > > "has" for keys (and possibly values of a Set, to preserve the value mapped to > boolean future option that forEach also supports), "contains" for values in > arrays > sounds ok, except we get the same issue for contains that we have for indexOf. II guess the big thing with contains is that it can be applied no non-indexed collections (maps, sets, etc.). Also any reason contains should be provided for WeakMap? I not seeing why it shouldn't be there too. Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
