String.prototype.contains and Set|Map.prototype.has naming consistency.

# Tobie Langel (13 years ago)

The lack of consistency between the naming of String.prototype.contains and (Set|Map).prototype.has bothers me (a little).

Both Ruby and Python display consistency for this (through the include? instance method and in operator respectively).

Maybe that's been discussed on the list already (can't find a search function for the archives, unfortunately).

If not, may I suggest both methods should be named the same?

And for extra consistency, an Array.prototype.(contains|has) would also be a nice addition.

Thanks for your time,

# T.J. Crowder (13 years ago)

Agree w/Tobie on both points (consistency btw String and Set/Map, and having it on Array as well). FWIW, prefer contains to has.

T.J. Crowder Independent Software Engineer tj / crowder software / com www / crowder software / com

# Mark S. Miller (13 years ago)

Makes sense for sets, where there's no difference between keys and values. For maps, I'd expect "contains" to test values, not keys.

# Allen Wirfs-Brock (13 years ago)

These really don't seem all that similar:

Map "has" is looking for a specific key used for the elements of a collection (Sets can be thought of as collections where keys and values area always the same) String "contains" is a search for a specific sequence of element values. One is about keys, the other is about values. One is about single elements, the other is about sequences of elements.

Consistent naming is important, but in this case I think using the same name would be conflating things that are actually quite different.

It seems to be that there are at least three dimensions of variability we should be considering when selecting consistent names for these kinds of operations:

  1. are they operating over object properties or elements of an abstract collection
  2. are the looking at keys or at values
  3. are they looking at individual elements or at sequences of elements

We wouldn't fill in this entire matrix and we have to live with legacy naming decisions, but it would be nice if going forward we consistently used method names that conformed to such a model.

# Strager Neds (13 years ago)

I agree with Allen.

I don't see the point in adding String#contains if `str.indexOf(x) >=

0` is equivalent (just like with arrays).

For sets, doing something like indexOf doesn't make sense (and a large part of sets is testing for inclusion, not indexing). For maps, the 'in' operator is unsuitable (as we all know from using a plain object as a hash map). Thus, both deserve a specialized method for these predicates.

In a further attempt to avoid confusion, would distinct 'hasKey' and 'hasValue' for Map.prototype be a good idea (instead of jumping around between has, contains, includes, isMember, etc.)?

(I'm at a loss to find the 'spec' being discussed; could someone point me in the right direction? I'm new to this list.)

# Rick Waldron (13 years ago)

On Sunday, May 20, 2012 at 3:31 PM, Strager Neds wrote:

I agree with Alle

I don't see the point in adding String#contains if str.indexOf(x) >= 0 is equivalent (just like with arrays).

For sets, doing something like indexOf doesn't make sense (and a large part of sets is testing for inclusion, not indexing). For maps, the 'in' operator is unsuitable (as we all know from using a plain object as a hash map). Thus, both deserve a specialized method for these predicates.

In a further attempt to avoid confusion, would distinct 'hasKey' and 'hasValue' for Map.prototype be a good idea (instead of jumping around between has, contains, includes, isMember, etc.)?

(I'm at a loss to find the 'spec' being discussed; could someone point me in the right direction? I'm new to this list.)

harmony:simple_maps_and_sets

# Quildreen Motta (13 years ago)

On 20/05/12 16:31, Strager Neds wrote:

I don't see the point in adding String#contains if str.indexOf(x)>= 0 is equivalent (just like with arrays).

str.contains(x)' has a clearer intent thanstr.indexOf(x) >= 0', in

your every-day app writer code. Though it's something that is rather easy to write an abstraction for, it's still something that's used mostly everywhere, so providing a convenience function for this out-of-the-box still has its value, imho.

I'd usually favour generic primitives that can be easily composed though, like a version of fold' that supports earlier end-of-iteration, such that you could writesome', every',find-first' and similar easily on top of it.