Last Comment Bug 560440 - Remove deprecated static fields of RegExp.prototype
: Remove deprecated static fields of RegExp.prototype
Status: RESOLVED WONTFIX
: dev-doc-complete
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal (vote)
: ---
Assigned To: general
:
Mentors:
: 437101 665372 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-19 20:19 PDT by Andreas Gal :gal
Modified: 2012-02-07 07:28 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Andreas Gal :gal 2010-04-19 20:19:49 PDT
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 Luke Wagner [:luke] 2010-04-19 22:28:49 PDT
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.
Comment 3 Brendan Eich [:brendan] 2010-04-20 22:42:05 PDT
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
Comment 4 Tom Schuster [:evilpie] 2011-12-04 10:07:59 PST
*** Bug 665372 has been marked as a duplicate of this bug. ***
Comment 5 Tom Schuster [:evilpie] 2011-12-04 10:29:39 PST
*** Bug 437101 has been marked as a duplicate of this bug. ***
Comment 6 Chris Leary [:cdleary] (not checking bugmail) 2011-12-05 09:26:40 PST
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.
Comment 7 jsp 2011-12-05 11:24:23 PST
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?
Comment 8 Eric Shepherd [:sheppy] 2012-02-07 05:47:59 PST
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.
Comment 9 jsp 2012-02-07 06:33:19 PST
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.
Comment 10 Eric Shepherd [:sheppy] 2012-02-07 07:28:34 PST
(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!

Note You need to log in before you can comment on or make changes to this bug.