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 function should not modify this matcher's state during
> 1138 * replacement. This method will, on a best-effort basis,
> throw a
> 1139 * {@link java.util.ConcurrentModificationException} if such
> 1140 * modification is detected.
> 1141 *
> 1142 *<p> The state of the match result is guaranteed to be constant
> 1143 * only for the duration of the function call and only if the
> 1144 * function does not modify this matcher's state.
>
>
> 1151 * @throws ConcurrentModificationException if it is detected, on a
> 1152 * best-effort basis, that the replacer function modified
> this
> 1153 * matcher's state
>
>
> Just wonder from API point of view, in theory the replacer should not be able
> to modify
> this matcher's state via a MatchResult, it is the side-effect of our
> implementation detail
> that happens to return "this matcher" as a MatchResult. For example, it
> should be possible
> to simply return a wrapper MatchResult on top of this matcher to only expose
> the read-only
> MatchResult methods, so the "replacer" will never be possible to modify the
> "matcher".
>
It's not really about casting a MatchResult to Matcher it's about the function
capturing the Matcher instance and operating on it.
> The modCount might still be good to have to catch the possible concurrent
> modification
> of the "matcher" while iterating, though the existing implementation does not
> do that for
> the original methods
>
> The "results" currently returns "heavy" clone of this matcher, it might be
> ideal
> to have a light weight MatchResult implementation with less fields and
> especially
> to a single "text.toString()", this might be helpful when the "text" is huge
> and it
> is not a "String" object.
Can you suggest, via code, such a lighter weight immutable implementation?
If there was a lighter weight alternative we could apply that to replace*
functions as well.
Paul.
