Naming discussion

[schuay]

I know I'm late to the party, but I wanted to raise this point as well since matchAll is highly unintuitive or even misleading to me.

matchAll suggests a variant of match that returns all matches, or possibly something related to global/nonglobal semantics. People seem to already fall into this kind of thinking as the discussions about the number of results produced by "ababa".matchAll(/aba/g) shows.

Correct me if I'm wrong, but the actual semantics are 'like match, but returns an iterator of result objects'. It's a pretty big mental leap to associate the 'all' in matchAll with 'complete result objects'.

I don't have suggestions for a better name myself. But FWIW I think both scan and matchIterator, as brought up at the September meeting, are both preferable to matchAll.

cc @mathiasbynens

[mathiasbynens]

The committee seemed to be strongly against setting the *iterator naming precedent (and I agree). OTOH, I had the impression that everyone was okay with scan. I don’t have a strong opinion on this myself but it was definitely interesting to see @schuay come up with similar feedback independently of @waldemarhorwat.

[ljharb]

The word "all" means "all matches you'd get if you looped over the string"; which is the only "all" anyone's ever really wanted or gotten in userland that I'm aware of.

What behavior would you expect "matchAll" to provide?

[schuay]

The word "all" means "all matches you'd get if you looped over the string"; which is the only "all" anyone's ever really wanted or gotten in userland that I'm aware of.

I have a different impression - what you're describing above sounds to me like @@match with a global regexp s.match(/./g).

The major differences between @@match and matchAll are the 1. iterator result, and 2. that the result contains complete RegExp match objects instead of just the matched substring. Those differences are not implied by the word "all", at least to me.

[ljharb]

match with a global regex doesn't provide what I need; which is the capturing groups. The goal of matchAll is to provide nested capturing groups in the match object; as match does for non-global regexes - because otherwise there's no good way to get it for global regexes.

What name do you suggest? scan has the same meaning in the Ruby world, but I'm told it has a different meaning in the FP world - it's better than blocking the proposal, but it's not that great a name.

[schuay]

match with a global regex doesn't provide what I need; which is the capturing groups.

I realize that, I was just saying that your description above ("all matches you'd get if you looped over the string") sounds to me like a simple global @@match call, and not the semantics provided by matchAll :)

What name do you suggest?

I'm not advocating for a particular name, I just feel that matchAll is not the best choice. Sorry, not very helpful, I know :(

scan has the same meaning in the Ruby world, but I'm told it has a different meaning in the FP world - it's better than blocking the proposal, but it's not that great a name.

The overload between FP and the parsing world already exists so that seems ok to me. What I like about this one is the consistency with at least 1 other language. I agree that it's not a very descriptive name though.

Looking at other languages:

In C#, Regex.Matches seems very similar. I like this name, but it's very similar to @@match.
Likewise in Python, re.finditer.
And the link to Ruby's scan just for reference: scan.

It's worth noting that matchAll has different semantics elsewhere:

pcre: preg_match_all is a global version of preg_match.

[ljharb]

"matches" also sounds like it's a predicate.

As for preg_*, those don't take flagged regexes, they take strings, so I'm not sure that's a relevant comparison.

[schuay]

Friendly ping, does anyone else have opinions?

I chatted about this with Brian (+cc @bterlson) and I think the gist was:

• matches and allMatches are not verbs and thus break the current convention (I think they're the most descriptive names though).
• Likewise matchIter. Not a verb, and contains iter.
• Brian liked scan, I'd be ok with it even though it's a bit nondescriptive.

[ljharb]

Committee consensus remains that the name should be matchAll.