StringMatcher

We have a CharMatcher but its capabilities are limited. I would like to have the ability to match more complex strings. Examples:

• Strings starting with three letters and ending with a digit (e.g. "var3", "abc8"): StringMatcher.inRange('a', 'z').times(3).then(StringMatcher.digit())
• Strings containing words with semicolons (e.g. "cat;dog;bird;"): StringMatcher.inRange('a', 'z').oneOrMore().then(StringMatcher.char(';')).oneOrMore()
• Strings representing integer numbers (e.g. "17", "-1"): StringMatcher.anyOf("-+").optional().then(StringMatcher.digit().oneOrMore())
• Strings containing either words or 123 (e.g. “bird”, "dDd", "123"): StringMatcher.inRange('a', 'z').or(StringMatcher.inRange('A','Z')).oneOrMore() .or(StringMatcher.str("123"))

Yes, these all can be done via regular expressions. But I hate regular expressions since they are not readable and not checked at compile time.

Do we need such feature in Guava?

[Stephan202]

@orionll, you seem to imply that people advocating for “just” using regular expressions don’t “care about the type safety and the quality of their software”. That’s kind of a blanket statement (or even a covert insult).

Note that the type safety provided by the proposed alternative would guard against syntax errors, but not necessarily semantic errors. The question is then: which category of error is the user of regular expressions more likely to make. The latter, I claim, because a dev will run the code they write at least once, thus uncovering syntax errors before they’re ever committed.

As for software quality: regular expressions are well understood and should be part of every developer’s toolkit. To invent an alternative could thus also be considered a case of NIH.

[orionll]

Thanks @jbduncan. I’m happy to know that there people who care about the type safety and the quality of their software.