On Feb 12, 2015, at 3:18 AM, Stuart Marks <[email protected]> wrote: > On 2/11/15 12:45 PM, Paul Sandoz wrote: >> On Feb 11, 2015, at 8:23 PM, Stuart Marks <[email protected]> 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. >
Thanks, added in place: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/ >>>> 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. Or a matter of how much the grossness is contained. In that respect the latter is more self-contained, the latter spreads out to all independent consumers of MatchResult. Paul.
