On Mar 3, 2015, at 3:09 AM, Stuart Marks wrote:
> On 3/2/15 1:49 AM, Paul Sandoz wrote:
>> On Feb 28, 2015, at 4:40 AM, Xueming Shen wrote:
>>> Updated to a static private class for the toMatchResult(). Added a private
>>> field MatchResult for the anonymous MatchResult
>>> wrapper.
>>>
>>> h
On 3/2/15 1:49 AM, Paul Sandoz wrote:
On Feb 28, 2015, at 4:40 AM, Xueming Shen wrote:
Updated to a static private class for the toMatchResult(). Added a private
field MatchResult for the anonymous MatchResult
wrapper.
http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/class
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 Shen wrote:
Updated to a static private class for the toMatchResult(). Added a private
field MatchResult for the anonymous MatchResult
wrapper.
http://cr.openjdk.ja
On Feb 28, 2015, at 4:40 AM, Xueming Shen wrote:
> Updated to a static private class for the toMatchResult(). Added a private
> field MatchResult for the anonymous MatchResult
> wrapper.
>
> http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/java/util/regex/Matcher.java
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 repetitive?
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?
http://cr.openjdk.java.net/~sherman/reg
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?
http://cr.openjdk.java.net/~sherman/regex.stream/src/java.base/share/classes/ja
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 Feb 27, 2015, at 7:48 PM, Xueming Shen wrote:
> On 02/27/2015 10:34 AM, Paul Sandoz wrote:
>> On Feb 27, 2015, at 7:18 PM, Xueming Shen wrote:
>>
>>> Hi Paul,
>>>
>>> 1133 * @param replacer
>>> 1134 * The function to be applied to the match result of this
>>> matcher
>>
On 02/27/2015 10:34 AM, Paul Sandoz wrote:
On Feb 27, 2015, at 7:18 PM, Xueming Shen 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 *
On Feb 27, 2015, at 7:18 PM, Xueming Shen 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 * The function should not modi
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 * The function should not modify this matcher's state during
1138 * replacement. Th
Hi,
On Feb 13, 2015, at 8:26 PM, Stuart Marks 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 there is :-)
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 13, 2015, at 1:20 AM, Stuart Marks 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 (expectedCount
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 tr
On Feb 12, 2015, at 9:43 AM, Peter Levart 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 replaceAll
On Feb 12, 2015, at 3:18 AM, Stuart Marks wrote:
> On 2/11/15 12:45 PM, Paul Sandoz wrote:
>> On Feb 11, 2015, at 8:23 PM, Stuart Marks 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" the
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, s
On 2/11/15 12:45 PM, Paul Sandoz wrote:
On Feb 11, 2015, at 8:23 PM, Stuart Marks 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.
O
On Feb 11, 2015, at 8:23 PM, Stuart Marks 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 to go,
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 Matche
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) Ad
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 convenience
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 sim
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 inc
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(Function ) that is more flexible than the
existing replaceAll that accepts a single value.
27 matches
Mail list logo
