Inline regexps and caching

Brendan Eich brendan at mozilla.com
Sat Jan 24 23:36:31 PST 2009


On Jan 24, 2009, at 10:56 PM, Richard Cornford wrote:

> All of that is true, and making sure the next language version  
> eliminates that is a good idea. But that does not help people who  
> have to address current ES 3 implementations.

The bug I cited,

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

claims IE and Safari do what ES3.1 specifies already. Pratap's JScript  
Deviations doc didn't mention this, at least not in the early form I  
just checked, and I can't test IE here. It's true for Safari 3.2.1.


>> To match the other kinds of literals and avoid bugs such as
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=474412
>
> Now that is an issue that relates to the identify of regular  
> expression objects, and so can only be addressed by creating  
> distinct objects with - new RegExp -.

The question of identity is potentially involved, unless you can show  
that resetting lastIndex but preserving the lexical singleton ES3  
conformance satisfies most of the complaints behind the highly-dup'ed  
bug

http://bugzilla.mozilla.org/show_bug.cgi?id=98409

(see http://weblogs.mozillazine.org/roadmap/archives/008325.html where  
the top three most-frequently dup'ed bugzilla.mozilla.org JS bugs were  
tabulated).

I'm not sure how much lastIndex resetting would help, but I know it  
would hurt those reporters who complain (also or separately) about the  
odd lexical singleton evaluation model. I'd rather fix regexp literals  
to evaluate like other mutable-object literals. This fix subsumes any  
ad-hoc fix for the lastIndex bug, for principled reasons: by  
eliminating implicit sharing of literally expressed mutable objects.


> "Can be addressed by ...", 'will be addressed by ...' and 'MUST be  
> addressed by ...' are all very different things. It is not in the  
> remit of the new specification to be requiring specific  
> optimisations in future implementations.

Of course not -- nor is it the spec's job to prematurely optimize at  
the expense of semantic cleanliness and principle-of-least-astonishment.

The market will sort out the implementation quality issue, and it's  
already forcing major performance work from all the top vendors. It  
won't happen overnight, but we've already got a cross-browser  
difference to deal with. Better to make the right long-term fix to the  
spec.


> 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.


> 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.

/be

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


More information about the Es-discuss mailing list