RegExp.$1 spec
Ugh, I'd forgotten about this. If it's implemented in all of IE,
Mozilla, Opera, and Safari, then it might be best to codify it in
ES4. OTOH we would then want to deprecate it. If we can let it alone
as a de-facto standard, not make it normative in the de-jure spec,
and thereby more effectively deprecate it, that would be best IMHO.
On 4/5/07, Brendan Eich <brendan at mozilla.org> wrote:
Ugh, I'd forgotten about this. If it's implemented in all of IE, Mozilla, Opera, and Safari, then it might be best to codify it in ES4. OTOH we would then want to deprecate it. If we can let it alone as a de-facto standard, not make it normative in the de-jure spec, and thereby more effectively deprecate it, that would be best IMHO.
Storing global state on shared global objects is script-friendly but bad practice for larger programs IMO (and is likely to interact poorly with future developments for multiprocessing). It interacts poorly with libraries too, since it allows library implementation (does it use regexes or String.prototype.indexOf?) can become visible. The order and timing of event handler firings (probably not 100% compatible between user agents) matters for program correctness. Etc.
The cat's out of the bag, but making the problem worse by condoning the practice does not seem right.
Does anyone know how widespread the use of this mechanism is?
On 4/6/07, Lars T Hansen <lth at acm.org> wrote:
Does anyone know how widespread the use of this mechanism is?
It is used quite a lot...
700 hits for RegExp.$\d www.google.com/codesearch?hl=en&lr=&q=RegExp.%24\d+lang%3Ajavascript&btnG=Search
6000 hits for RegExp www.google.com/codesearch?as_q=RegExp&btnG=Search+Code&hl=en&as_lang=javascript&as_license_restrict=i&as_license=&as_package=&as_filename=&as_case=y
So about 10% of the JavaScript code that uses RegExp also uses the RegExp.$n notation.
Just a random thought: What if we made it permissible in standard mode, but illegal in strict mode? That would give us backward compatibility and reinforce the idea that it's a scripting-friendly practice that is not a good idea for larger programs.
Francis
On 4/6/07, Francis Cheng <fcheng at adobe.com> wrote:
Just a random thought: What if we made it permissible in standard mode, but illegal in strict mode? That would give us backward compatibility and reinforce the idea that it's a scripting-friendly practice that is not a good idea for larger programs.
If I read the strict-and-standard proposal correctly, strict mode has no run-time impacts; all it does is layer compile-time checking (and rejection of some programs) onto a common run-time language.
On the other hand, there is the "better eval" discussion from the January f2f which might be interpreted as strict mode having effects on run-time behavior, and that would create some sort of precedent for what you're suggesting. But it has not yet been written up as a coherent proposal (it's only in the meeting notes).
I like the cleanliness of the current strict-and-standard proposal, and I hope we can keep the run-time behavior invariant on whether strict mode is in effect. In that sense I don't like outlawing $n in strict mode; I'm also not sure about whether it's good software engineering to do so (programs will typically consist of some chunks compiled in strict mode and others in standard mode).
But I'll put all of this on the agenda for the next f2f.
At the latest face-to-face, we agreed:
-
strict mode selects a different eval implementation, which rejects
program source containing binding forms other than let and its
variations (var, function), to prevent new names from being
introduced into eval's dynamic scope, frustrating static analyses
including optimization. -
Otherwise strict mode rejects certain programs at compile time but
changes no runtime semantics. -
We decided to leave RegExp.$n unspecified, so it can wither and die.
I cannot find any spec for how RegExp.$1 etc should work. It is not part of the 3rd edition but all user agents seems to implement this. Is there a spec for this somewhere? Should this be added to edition 4?