Regex on substrings

Brendan Eich brendan at mozilla.com
Thu Jun 2 15:41:25 PDT 2011


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 <mikesamuel at gmail.com> wrote:
>> 2011/6/2 Peter van der Zee <ecma at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list