On 2/11/15 12:45 PM, Paul Sandoz wrote:
On Feb 11, 2015, at 8:23 PM, Stuart Marks <stuart.ma...@oracle.com> wrote:
That "matches" my original thinking on the matter and is reflected in the patch. It's
very simple to support. If the method was named "findAll" then it would be misleading and
imply a reset was needed.
OK, good, I see that, so it doesn't need to be changed.
Ok, the first webrev i sent is already implemented as agreed so lets review
that code.
I looked at:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
I think this was before you added Pattern.replaceFirst(), so that should be
retrofitted here.
Regarding the disparity between MatchResult and Matcher. I think that would
require a new sub-interface of MatchResult from which Matcher extends from and
returns. If we think it important we should do that for 9 otherwise we will be
stuck for the stream-based methods.
Why do you think we need a new sub-interface? Wouldn't it be sufficient to add
default methods?
What would the defaults do? Throwing an exception seems a poor solution to me.
My guess it will be possible to evolve Matcher in binary and source compatible
way to use the sub-type.
OK, I filed an RFE to cover this, then immediately closed it as a duplicate :-)
because I failed to search for the existing RFE that covers this:
https://bugs.openjdk.java.net/browse/JDK-8065554
Either we add some default methods that throw exceptions (gross) or we add a
sub-interface (also gross). It might be a matter of taste, or bike shed
painting. Either way, I think this needs to be done.
s'marks
Paul.
There is of course the possibility of existing 3rd party classes that implement
MatchResult having conflicting methods. But I don't think MatchResult is
implemented quite as often as the collection interfaces, where we've been
reticent to add default methods because of so many implementations.
I did a quick web search and I did find a few implementations/extensions of
MatchResult, but there were no obvious conflicts. This isn't definitive, of
course.
The default implementations of group(String), start(String), and end(String)
could throw IllegalArgumentException, since that's what the ones on Matcher do
if there's no such named capture group.
I admit this is a little weird, since it's only safe to use these new methods
if you know where the MatchResult instance came from. So logically perhaps it's
a different type. My hunch, though, is that MatchResults aren't passed around,
they're created from Patterns/Matchers and processed within the same code, so
in practice this won't be a problem.
s'marks
