On Mar 3, 2015, at 3:09 AM, Stuart Marks stuart.ma...@oracle.com wrote:
On 3/2/15 1:49 AM, Paul Sandoz wrote:
On Feb 28, 2015, at 4:40 AM, Xueming Shen xueming.s...@oracle.com wrote:
Updated to a static private class for the toMatchResult(). Added a private
field MatchResult for the
On 3/2/15 1:49 AM, Paul Sandoz wrote:
On Feb 28, 2015, at 4:40 AM, Xueming Shen xueming.s...@oracle.com wrote:
Updated to a static private class for the toMatchResult(). Added a private
field MatchResult for the anonymous MatchResult
wrapper.
On Feb 28, 2015, at 4:40 AM, Xueming Shen xueming.s...@oracle.com wrote:
Updated to a static private class for the toMatchResult(). Added a private
field MatchResult for the anonymous MatchResult
wrapper.
Hi Paul, it looks good to me.
Thanks,
-Sherman
On 03/02/2015 01:49 AM, Paul Sandoz wrote:
On Feb 28, 2015, at 4:40 AM, Xueming Shenxueming.s...@oracle.com wrote:
Updated to a static private class for the toMatchResult(). Added a private
field MatchResult for the anonymous MatchResult
On 2/27/15 3:19 PM, Stuart Marks wrote:
On 2/27/15 12:40 PM, Xueming Shen wrote:
On 02/27/2015 11:21 AM, Xueming Shen wrote:
On 02/27/2015 10:55 AM, Paul Sandoz wrote:
What about a light wright immutable MatchResult? is that possible?
Should be possible. I can give it try.
too
Hi,
On Feb 13, 2015, at 8:26 PM, Stuart Marks stuart.ma...@oracle.com wrote:
OK, this looks great. Thanks for the updates.
There is also
in same order - in the same order
in the doc for the results() method, as Brian pointed out internally.
No need for another webrev.
Alas
On 02/27/2015 10:34 AM, Paul Sandoz wrote:
On Feb 27, 2015, at 7:18 PM, Xueming Shenxueming.s...@oracle.com wrote:
Hi Paul,
1133 * @param replacer
1134 * The function to be applied to the match result of this
matcher
1135 * that returns a replacement string.
On Feb 27, 2015, at 7:48 PM, Xueming Shen xueming.s...@oracle.com wrote:
On 02/27/2015 10:34 AM, Paul Sandoz wrote:
On Feb 27, 2015, at 7:18 PM, Xueming Shenxueming.s...@oracle.com wrote:
Hi Paul,
1133 * @param replacer
1134 * The function to be applied to the match
On Feb 27, 2015, at 7:18 PM, Xueming Shen xueming.s...@oracle.com wrote:
Hi Paul,
1133 * @param replacer
1134 * The function to be applied to the match result of this
matcher
1135 * that returns a replacement string.
1136 *
1137 *p The
Hi Paul,
1133 * @param replacer
1134 * The function to be applied to the match result of this
matcher
1135 * that returns a replacement string.
1136 *
1137 *p The function should not modify this matcher's state during
1138 * replacement.
On 02/27/2015 11:21 AM, Xueming Shen wrote:
On 02/27/2015 10:55 AM, Paul Sandoz wrote:
What about a light wright immutable MatchResult? is that possible?
Should be possible. I can give it try.
too repetitive?
On 02/27/2015 10:55 AM, Paul Sandoz wrote:
What about a light wright immutable MatchResult? is that possible?
Should be possible. I can give it try.
On 2/27/15 12:40 PM, Xueming Shen wrote:
On 02/27/2015 11:21 AM, Xueming Shen wrote:
On 02/27/2015 10:55 AM, Paul Sandoz wrote:
What about a light wright immutable MatchResult? is that possible?
Should be possible. I can give it try.
too repetitive?
On Feb 13, 2015, at 1:20 AM, Stuart Marks stuart.ma...@oracle.com wrote:
On 2/12/15 3:15 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
OK, overall looks pretty good. Two minor comments on Matcher.java:
1202 if
OK, this looks great. Thanks for the updates.
There is also
in same order - in the same order
in the doc for the results() method, as Brian pointed out internally.
No need for another webrev.
s'marks
On 2/13/15 1:17 AM, Paul Sandoz wrote:
On Feb 13, 2015, at 1:20 AM, Stuart Marks
On Feb 12, 2015, at 9:43 AM, Peter Levart peter.lev...@gmail.com wrote:
On 02/11/2015 08:23 PM, Stuart Marks wrote:
1.1) Change the specification of Matcher.results to reset the stream before
matching, making it consistent with the replace* methods.
I'm not sure about this. The current
On Feb 12, 2015, at 3:18 AM, Stuart Marks stuart.ma...@oracle.com wrote:
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.
On 2/12/15 3:15 AM, Paul Sandoz wrote:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
OK, overall looks pretty good. Two minor comments on Matcher.java:
1202 if (expectedCount = 0 expectedCount != matchOrResetCount)
1203 return
On 02/11/2015 08:23 PM, Stuart Marks wrote:
1.1) Change the specification of Matcher.results to reset the stream
before matching, making it consistent with the replace* methods.
I'm not sure about this. The current replaceAll/replaceFirst methods
reset the matcher before doing any matching,
On 2/11/15 2:25 AM, Paul Sandoz wrote:
Hi Stuart,
Thanks for the detailed review.
Here is a possible way forward:
1) Add the methods to Matcher, as proposed in the initial webrev.
Yes, I think this is the way to go, and it seems that Sherman concurs.
1.1) Change the specification of
Hi
It might be more consistent with the existing design to add those
methods into Matcher. I agree the
better name for the stream return method is findAll.
-sherman
On 2/11/15 2:25 AM, Paul Sandoz wrote:
Hi Stuart,
Thanks for the detailed review.
Here is a possible way forward:
1) Add
On Feb 11, 2015, at 8:23 PM, Stuart Marks stuart.ma...@oracle.com wrote:
On 2/11/15 2:25 AM, Paul Sandoz wrote:
Hi Stuart,
Thanks for the detailed review.
Here is a possible way forward:
1) Add the methods to Matcher, as proposed in the initial webrev.
Yes, I think this is the way
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
Hi Stuart,
Thanks for the detailed review.
Here is a possible way forward:
1) Add the methods to Matcher, as proposed in the initial webrev.
1.1) Change the specification of Matcher.results to reset the stream before
matching, making it consistent with the replace* methods.
2) Add
Hi Paul,
I spent some time looking at this API. Overall it seems to me that things work a
bit more nicely when these methods are added to Pattern instead of Matcher.
Unfortunately there are some odd things with the existing API that make this
tradeoff not so obvious.
First, here's what a
Here is an alternative that pushes the methods on to Pattern instead:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/on-Pattern/webrev/
(Whe webrev reports some files as empty, please ingore those, i have this
webrev stacked on the previous one.)
I have also
Hi.
Please review these stream/lambda enhancements on Matcher:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/
Two new methods are added to Matcher:
1) replaceAll(FunctionMatchResult, String ) that is more flexible than the
existing replaceAll that
27 matches
Mail list logo
