/**
* <tt>SearchIterator</tt> is an abstract base class that provides
* methods to search for a pattern within a text string. Instances of
- * <tt>SearchIterator</tt> maintain a current position and scans over the
+ * <tt>SearchIterator</tt> maintain a current position and scan over the
* target text, returning the indices the pattern is matched and the length
* of each match.
* <p>
* matching based on the comparison rules defined in a
* <tt>RuleBasedCollator</tt> object.
* <p>
- * Other options for searching includes using a BreakIterator to restrict
+ * Other options for searching include using a BreakIterator to restrict
* the points at which matches are detected.
* <p>
* <tt>SearchIterator</tt> provides an API that is similar to that of
* other text iteration classes such as <tt>BreakIterator</tt>. Using
- * this class, it is easy to scan through text looking for all occurances of
+ * this class, it is easy to scan through text looking for all occurrences of
* a given pattern. The following example uses a <tt>StringSearch</tt>
* object to find all instances of "fox" in the target string. Any other
* subclass of <tt>SearchIterator</tt> can be used in an identical
* Note:
*
* ICU4J already exposed some protected members such as
- * targetText, brekIterator and matchedLength as a part of stable
+ * targetText, breakIterator and matchedLength as a part of stable
* APIs. In ICU4C, they are exposed through USearch struct,
* although USearch struct itself is internal API.
*
- * This class was created for making ICU4J code in parallel to
+ * This class was created for making ICU4J code parallel to
* ICU4C implementation. ICU4J implementation access member
* fields like C struct (e.g. search_.isOverlap_) mostly, except
* fields already exposed as protected member (e.g. search_.text()).
// Java porting note:
//
-// ICU4C implementation contains dead code in many places.
-// While porting ICU4C linear search implementation, these dead codes
-// were not fully ported. The code block tagged by "// *** Boyer-Moore ***"
-// are those dead code, still available in ICU4C.
+// The ICU4C implementation contains dead code in many places.
+// While porting the ICU4C linear search implementation, this dead code
+// was not fully ported. The code blocks tagged by "// *** Boyer-Moore ***"
+// are those dead code blocks, still available in ICU4C.
-// ICU4C implementation does not seem to handle UCharacterIterator pointing
-// a fragment of text properly. ICU4J uses CharacterIterator to navigate through
+// The ICU4C implementation does not seem to handle UCharacterIterator pointing
+// to a fragment of text properly. ICU4J uses CharacterIterator to navigate through
// the input text. We need to carefully review the code ported from ICU4C
// assuming the start index is 0.
-// ICU4C implementation initializes pattern.CE and pattern.PCE. It looks
-// CE is no longer used, except a few places checking CELength. It looks this
-// is a left over from already disable Boyer-Moore search code. This Java implementation
-// preserves the code, but we should clean them up later.
+// ICU4C implementation initializes pattern.CE and pattern.PCE. It looks like
+// CE is no longer used, except in a few places checking CELength. It looks like this
+// is a leftover from already-disabled Boyer-Moore search code. This Java implementation
+// preserves the code, but we should clean this up later.
/**
*
* there exists no non-ignorable combining mark before or after S?
* in S respectively.
* </pre>
- * Option 2. will be the default.
+ * Option 2. is the default.
* <p>
* This search has APIs similar to that of other text iteration mechanisms
* such as the break iterators in {@link BreakIterator}. Using these
* <p>
* {@link SearchIterator} provides APIs to specify the starting position
* within the text string to be searched, e.g. {@link SearchIterator#setIndex setIndex},
- * {@link SearchIterator#preceding preceding} and {@link SearchIterator#following following}. Since the
- * starting position will be set as it is specified, please take note that
- * there are some danger points which the search may render incorrect
+ * {@link SearchIterator#preceding preceding} and {@link SearchIterator#following following}.
+ * Since the starting position will be set as it is specified, please take note that
+ * there are some danger points at which the search may render incorrect
* results:
* <ul>
- * <li> The midst of a substring that requires normalization.
+ * <li> In the midst of a substring that requires normalization.
* <li> If the following match is to be found, the position should not be the
- * second character which requires to be swapped with the preceding
- * character. Vice versa, if the preceding match is to be found,
+ * second character which requires swapping with the preceding
+ * character. Vice versa, if the preceding match is to be found, the
* position to search from should not be the first character which
- * requires to be swapped with the next character. E.g certain Thai and
+ * requires swapping with the next character. E.g certain Thai and
* Lao characters require swapping.
* <li> If a following pattern match is to be found, any position within a
* contracting sequence except the first will fail. Vice versa if a
- * preceding pattern match is to be found, a invalid starting point
+ * preceding pattern match is to be found, an invalid starting point
* would be any character within a contracting sequence except the last.
* </ul>
* <p>
* <p>
* Options are provided to handle overlapping matches.
* E.g. In English, overlapping matches produces the result 0 and 2
- * for the pattern "abab" in the text "ababab", where else mutually
- * exclusive matches only produce the result of 0.
+ * for the pattern "abab" in the text "ababab", where mutually
+ * exclusive matches only produces the result of 0.
* <p>
* Though collator attributes will be taken into consideration while
* performing matches, there are no APIs here for setting and getting the
projects / icu / commitdiff