Andrea Giammarchi wrote:
I actually agree on this, but Set.has() is misleading then, imho.
Shouldn't be specified that `has()` is key related and `contains()` is
value related?
The forEach signature has (value, key, collection), and for a Set is
called with (value, value, theSet). We discussed this at the Boston f2f
and recently on list. It allows us to extend Sets in the future (under
object model reformation, e.g.) to map value to boolean has-result.
Apart from the Set special case, using contains for values and has for
keys seems better and better to me. But that means
String.prototype.contains, not has. The test is for values, not keys, in
that case. Same thing with Array.prototype.contains (and MooTools must
adapt).
/be
Also a "magic" Object.has(obj, key) with smart obj recognition and
Object.contains(obj, value) would be probably cool
On Fri, Nov 2, 2012 at 2:30 PM, Allen Wirfs-Brock
<al...@wirfs-brock.com <mailto:al...@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
<dome...@domenicdenicola.com
<mailto:dome...@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@mozilla.org <mailto:es-discuss@mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
