Inline regexps and caching

Brendan Eich brendan at mozilla.com
Sat Jan 24 18:48:03 PST 2009


On Jan 24, 2009, at 5:42 PM, Richard Cornford wrote:

> Ugly, and an example of using a hammer to crack a nut.

I do this all the time, works great ;-).

Seriously, there's more afoot than can be patched by resetting  
lastIndex.


> The issue is provoked by the fact that for a regular expression with  
> the global flag set the - exec - method employs the regular  
> expression object's - lastIndex - property, leaving it set to the  
> end index of the last match made. Knowing that suggests that a  
> simple 'solution' would be to explicitly set the regular expression  
> object's - lastIndex - property to zero before using it. That must  
> be cheaper than creating a new regular expression object just for  
> the side effect of then having one with a zero - lastIndex - property.

The more general problem is shared mutable literal-expressed  
singletons. In no other case (object or array initialiser, function  
expressions, primitive literals) does evaluation return the singleton  
created as if at parse time. Mutation hurts, sharing should be  
explicit. To match the other kinds of literals and avoid bugs such as

https://bugzilla.mozilla.org/show_bug.cgi?id=474412

Efficiency concerns are secondary but can be addressed by lightweight  
cloning of a shared-immutable compiler-created regexp.


> In addition, knowing the mechanism also directs attention towards  
> the global flag; does the regular expression being used need to have  
> the global flag set in the first place? If the flag is not set then  
> subsequent - exec - uses will always start at the zero index. The  
> example regular expression used above only appears to be interested  
> in making a single match so probably there was never a need to have  
> the flag set.

This is an optimization challenge for implementors, not a reason to  
specify a shared singleton with mutable state (lastIndex is mutable  
and set to 0 even without the 'g' flag).

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090124/8cf664b7/attachment.html>


More information about the Es-discuss mailing list