Note that http://wiki.ecmascript.org/doku.php?id=harmony:regexp_y_flag
has been promoted to harmony:proposals status (see http://wiki.ecmascript.org/doku.php?id=harmony:proposals), so very likely to be in ES.next. With this flag on a regexp, you don't need extra arguments for a suite of methods. Instead you set the regexp's lastIndex property (or let it start at 0 and then be updated by successive matches -- the y flag causes updates to lastIndex in the same way that the g flag does). As for matching $ at the end, that is a less common use-case not served by the y flag. Usually you are lexing through a string and want to avoid an anchoring search, and of course avoid taking tail slices at each lastIndex. But the lexer munches according to a regular grammar and knows when to stop. It is atypical to want $ to match exactly N characters from the anchor point. /be On Jun 2, 2011, at 10:32 AM, Peter van der Zee wrote: > On Thu, Jun 2, 2011 at 7:17 PM, Mike Samuel <mikesam...@gmail.com> wrote: >> 2011/6/2 Peter van der Zee <e...@qfox.nl>: >>> A problem I faced recently is the inability to apply regular >>> expressions to a substring of a string without explicitly taking the >>> substring first. So I'm wondering how much trouble it would be to >>> extend the RegExp api to this... >>> >>> RegExp.prototype.test = function(string[, start=0[, stop=string.length]]){ >>> }; >>> RegExp.prototype.exec = function(string[, start=0[, stop=string.length]]){ >>> }; >> >> What do the ^ and $ assertions in non-multiline mode mean when start >> and stop are not [0, string.length)? >> Do they match at the beginning and end of the substring? > > They mean exactly the same as they would do for > regex.test(string.substring(start, stop)) > >> >>> Optionally, it might be handy to have .test return a number, >>> indicating the length of the (first) match. If zero, there was no >>> match. This would however break with scripts that explicitly check for >>> === false. >> >> Using zero to indicate that there is no match will conflate zero >> length matches with no match. >> Consider >> >> /\b/.test("a-b") === true > > That's a good point. It suppose could return false, but that wouldn't > be very backcompat for these cases. It could return -1 but that would > definately be backcompat breaking. > > Well, it would have been nice. But if the tax on returning match > length for .test is too big I'm not feeling that strong about it > myself. > > - peter > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
