Inline regexps and caching
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,
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
> 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
(see http://weblogs.mozillazine.org/roadmap/archives/008325.html where
the top three most-frequently dup'ed bugzilla.mozilla.org JS bugs were
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss