Similarly, I think we should see at least getOneArbitraryMatch(), hasMatch(), countMatches(), forEachMatch(processor), forOneArbitraryMatch(processor)
Btw. I'm still looking for a _good_ suggestion on how to "include" inherited methods (other than pointing to the Javadoc, which is what we have now).
Well, in the worst case we can just "lie" and copy these methods into the class body, as if they were declared there.
And instead of extends BaseGeneratedMatcher, we could say implements IncQueryMatcher, to suggest the generic interface.
We could do the same for the Match class.
6. the generic API is demonstrated with the pattern FQN, which is only useful if the corresponding matcher factory has been registered, which typically happen with generated matcher factories only. In case of Patterns cobbled together at runtime, parameterize the matcher factory with the Pattern - especially that the comments explicitly say this.
very good point. the question is
- is this a supported/endorsed use case now?
- is there any working example on how to do this?
Isn't this how the Query Explorer displays matches for patterns loaded from .eiq?
Pro: a bit simpler.
Con: more difficult to use.
Refactoring to a strictly typed version is possible, the question is whether we should do it.
