Remove deprecated static fields of RegExp.prototype

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
RESOLVED WONTFIX
7 years ago
6 years ago

People

(Reporter: gal, Unassigned)

Tracking

({dev-doc-complete})

Trunk
x86
Mac OS X
dev-doc-complete
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Deprecated_Features#RegExp_Methods

Its ugly, its slow (bug 560358), its a potential information leak that needs special wrapper treatment, and its non-standard. Time to nuke it from orbit.

This will eliminate cx->regExpStatics and all the cruft associated with it. It will also greatly streamline and simplify the match path of regexps.

Comment 1

7 years ago
Flat string matching is used for str_search, str_match, and str_replace to avoid costly regexp paths (also StringMatch is getting pretty fast (bug 558270)).  I wimped out on doing flat matching for regexps that don't contain meta-chars precisely because of all the RegExp static field gunk required to not break it.  With them gone, it would be fairly easy to do.
For the record: http://mxr.mozilla.org/mozilla-central/search?string=RegExp.%24&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central
Also:

http://www.google.com/codesearch?as_q=RegExp\.\%24&btnG=Search+Code&hl=en&as_lang=javascript&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=

I wish Google had used its wealth to pay for these sites and programs to be rewritten, but they stealthed v8 and missed that chance.

We are not going to break the web this much, much as I would love to nuke the RegExpStatics from orbit.

Study the affected JS code, come up with a better plan that keeps compatibility.

/be
Duplicate of this bug: 665372
Duplicate of this bug: 437101
I think this is a WONTFIX -- we can't change this without breaking the web, unless some ES opt-in de jure says that these no longer exist.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX

Comment 7

6 years ago
Any page on the Web that uses RegExp.$1...$9 is already skating on thin ice, as discussed in bug 437101 and bug 320811, because extensions may modify the values before they're used.  (Unless bug 571355 addresses that problem; that bug is way beyond me.)

Is there some mechanism that could be used to warn developers of the dangers of using RegExp.$1...$9, perhaps when they're running under a debugger?
Keywords: dev-doc-needed
Noted that $1...$9 are deprecated and should not be used (and enhanced the warnings against them where already noted):

https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/replace
https://developer.mozilla.org/en/JavaScript/Reference/Deprecated_Features#RegExp_Properties

Could not find anywhere else that mentions this syntax; if you do, please let me know.
Keywords: dev-doc-needed → dev-doc-complete

Comment 9

6 years ago
The "Specifying a string as a parameter" section of https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/replace says $n and $nn are non-standard and deprecated and should not be used. This is wrong; they're (currently) documented on page 147 of http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf. They are replacement patterns, distinct from the RegExp.$n global properties despite the similarity.

The deprecated features page looks fine.
(In reply to jsp from comment #9)
> The "Specifying a string as a parameter" section of
> https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String/
> replace says $n and $nn are non-standard and deprecated and should not be
> used. This is wrong; they're (currently) documented on page 147 of
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf.
> They are replacement patterns, distinct from the RegExp.$n global properties
> despite the similarity.
> 
> The deprecated features page looks fine.

Fixed; sorry about that!
You need to log in before you can comment on or make changes to this bug.