I'm looking at the source code of this package.

What is supposed to be the contract of:
- PatterMatcher.getMatcher(String expression)
- Matcher.matches(String input)

In both cases I see absolutely no reason to accept a null argument.
As far as I can read implementation differs regarding the acceptance of null. Some will deal with it and go the extra step to compare null to null, some will blow up. GlobPatternMatcher goes the extra work of not blowing up if the pattern syntax is invalid (but logging a message) and will later if the compiled pattern is null returns true if the input is null too. That's pretty wild and you can be sure that it will do the wrong thing and no one will notice.

So it's not consistent and needs to be fixed so that it is more clear.
Do you agree that:
- The GlobPattern MUST failed (just like the regexp one) if the pattern syntax is invalid.
- The expression must not be null.
- The input must not be null


Don't bother to fix anything, I will be hopefully cleaning some code, documenting it (javadoc) and writing testcases.
And I'd like to remove this getInstance that is really annoying too.

Bonus question: Matcher.isExact(). While I understand that it is to figure if a match is an exact match (vs a partial match)... I failed to see the reason that motivated this method. If I want to be nasty I could write a regexp which is an exact match while the matcher will return that is not an exact match (because in practice you only know if a matcher is exact only after doing it). and that's the same for the ExactOrRegexp which can do an exact match but it says it is not. I see that the isExact() is actually only used once. For install(). And I'm not exactly sure to understand what implication it has (I could go deeply in the code but think a short explanation of the rationale behind it is certainly more interesting )

Thanks !

-- stephane

Reply via email to