In that case I wouldn't put this new functionality in the Collator object. A new StringSearch or StringIterator object would make more sense:<div><br></div><div>options = {</div><div>  collator[optional - default, collatorType=search],</div>
<div>  source[required],</div><div>  pattern[required]</div><div>}</div><div>LocaleInfo.StringIterator = function(options) {}</div><div>LocaleInfo.StringIterator.prototype.first = function() { find first occurrence}</div>
<div>LocaleInfo.StringIterator.prototype.next = function() { get me next occurrence of pattern in source}</div><div>LocaleInfo.StringIterator.prototype.matchLength = function() { length of the match }</div><div>... (reset, setPosition...)<br>
<br><div class="gmail_quote">25. март 2011. 15.14, Mark Davis ☕ <span dir="ltr"><<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>></span> је написао/ла:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font face="georgia,serif">I think an iterator is a cleaner interface; we were just trying to minimize new API.</font><div><font face="georgia, serif"><br></font></div><div><font face="georgia,serif"></font><font face="georgia, serif">In general, collation is context sensitive, so searching on substrings isn't a good idea. You want to search from a location, but have the rest of the text available to you.<br>

</font><div><font face="georgia, serif"><br></font></div><div><font face="georgia,serif"></font><font face="georgia, serif">For the iterator, you would need to be able to reset to a location, but the context beforehand could affect what happens.<br>

</font><div><font face="georgia,serif"><br clear="all"></font><font face="georgia, serif">Mark<br><br><i>— Il meglio è l’inimico del bene —</i></font><div><div></div><div class="h5"><br>
<br><br><div class="gmail_quote">On Fri, Mar 25, 2011 at 14:22, Mike Samuel <span dir="ltr"><<a href="mailto:mikesamuel@gmail.com" target="_blank">mikesamuel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2011/3/25 Mike Samuel <<a href="mailto:mikesamuel@gmail.com" target="_blank">mikesamuel@gmail.com</a>>:<br>
<div><div></div><div>> 2011/3/25 Nebojša Ćirić <<a href="mailto:cira@google.com" target="_blank">cira@google.com</a>>:<br>
>> find method wouldn't return boolean but an array of two values:<br>
><br>
> Sorry if I wasn't clear.  The !! at the beginning of the call to find<br>
> is important.<br>
> The undefined value you mentioned below as possible no match result is<br>
> falsey because !!undefined === false.<br>
><br>
>> myCollator.find('gaard', 'ard', 2) -> [2, 5]  // 4 or 5 as a bound<br>
>> myCollator.find('ard', 'ard', 0) -> [0, 3]  // 2 or 3 as a bound<br>
>> I guess [2, 5] !== [0, 3]<br>
><br>
> True, but also [2, 5] !== [2, 5].<br>
><br>
>> We could return [-1, undefined] for not found state, or just undefined.<br>
><br>
>> I agree that returning a boolean makes for easier tests in loops.<br>
><br>
><br>
>> 25. март 2011. 14.00, Mike Samuel <<a href="mailto:mikesamuel@gmail.com" target="_blank">mikesamuel@gmail.com</a>> је написао/ла:<br>
>>><br>
>>> 2011/3/25 Nebojša Ćirić <<a href="mailto:cira@google.com" target="_blank">cira@google.com</a>>:<br>
>>> > Looking through the notes from the meeting I also found some problems<br>
>>> > with<br>
>>> > the collator. We did specify the collatorType: search, but we didn't<br>
>>> > offer a<br>
>>> > function that would make use of it. Mark and I are thinking about:<br>
>>> > /**<br>
>>> >  * string - string to search over.<br>
>>> >  * substring - string to look for in "string"<br>
>>> >  * index - start search from index<br>
>>> >  * @return {Array} [first, last] - first is index of the match or -1,<br>
>>> > last<br>
>>> > is end of the match or undefined.<br>
>>> >  */<br>
>>> > LocaleInfo.Collator.prototype.find(string, substring, index)<br>
>>> > We could also opt for iterator solution where we keep the state.<br>
>>><br>
>>> Assuming find returns a falsey value when nothing is found, is it the<br>
>>> case that for all (string, index) pairs,<br>
>>><br>
>>> !!myCollator.find(string, substring, index) ===<br>
>>> !!myCollator.find(string.substring(index), substring, 0)<br>
<br>
</div></div>Maybe a better way to phrase this relation is<br>
<br>
will any collator ever look at a code-unit to the left of index when<br>
trying to determine whether there is a match at or after index?<br>
<br>
E.g. if the code-unit at index might be a strict suffix of a substring<br>
that could be represented as a one codepoint ligature.<br>
<div><div></div><div><br>
<br>
>>> This would be false if the substring 'ard' should be found in 'gard',<br>
>>> but not 'gaard' because then<br>
>>><br>
>>>     !!myCollator.find('gaard', 'ard', 2) !== !!myCollator.find('ard',<br>
>>> 'ard', 0)<br>
>>><br>
>>><br>
>>> If that relation does not hold, then exposing find as an iterator<br>
>>> might help prevent a profusion of subtly wrong loops.<br>
>>><br>
>>><br>
>>> > The reason we need to return both begin and end part of the found string<br>
>>> > is:<br>
>>> > Look for gaard and we find gård - which may be equivalent in Danish, but<br>
>>> > substring lengths don't match (5 vs. 4) so we need to tell user the next<br>
>>> > index position.<br>
>>> > The other problem Jungshik found is that there is a combinatorial<br>
>>> > explosion<br>
>>> > with all ignoreXXX options we defined. My proposal is to define only N<br>
>>> > that<br>
>>> > make sense (and can be supported by all implementors) and fall back the<br>
>>> > rest<br>
>>> > to some predefined default.<br>
>>><br>
>>><br>
>>><br>
>>> > --<br>
>>> > Nebojša Ćirić<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > es-discuss mailing list<br>
>>> > <a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
>>> > <a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
>>> ><br>
>>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Nebojša Ćirić<br>
>><br>
><br>
_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div></div></blockquote></div><br></div></div></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Nebojša Ćirić<br>
</div>