Inline regexps and caching

Richard Cornford Richard at litotes.demon.co.uk
Sun Jan 25 15:53:53 PST 2009


Brendan Eich wrote:
> On Jan 24, 2009, at 10:56 PM, Richard Cornford wrote:
<snip>
>> I am not saying that there should be a shared singleton. In
>> the situation as we have it now there are implementations
>> that create regular expression literals while parsing, and
>> others that create them when the expression is evaluated.
>
> The latter are not conforming to ES3, FWIW. The spec is clear.

They are not conforming, but their (now long-term) existence has prevented
people form expecting conformity in this area. Which becomes the thing
that allows the new spec to change the way regular expression literals are
handled.

>> So it is not possible to rely on the former or expect the
>> latter. The result is a minefield that needs to be cleaned
>> up. But in the meanwhile bulldozing all regular expression
>> uses with - new RegExp - seems an extreme alternative to
>> recognising the few that can blow up in your face and
>> diffusing them individually.
>
> Oh, I didn't mean to argue against your argument with Mark's
> advice to use new RegExp(...) exclusively and never use
> literals! Sorry if I misread you, I thought you were arguing
> for lastIndex resetting as an alternative to the 3.1 evaluation
> change.

It would never have been realistic/practical to change the way -
lastIndex - is handled in the - exec - method as that would break code
such as:-

var m, rx = / ... /g;
while (( m =  rx.exec( st ) )){
   ... // handle each successive match in turn.
}

- which, even if not often seen, is something people do.

Fortunately the existing non-conforming implementations will have
prevented the variation:-

var m;
while (( m =  / ... /g.exec( st ) )){
    ... // handle each successive match in turn.
}

-  which would otherwise have been broken by getting rid of the shared
singleton.

Richard Cornford.



More information about the Es-discuss mailing list