Most programming languages have keywords or reserved words: names which can’t be used to name variables. Keywords have special meaning, so using them as variable names would conflict with such use. Reserved words are keywords of the future: names which might eventually be given special meaning, so they can’t be used now to ease future adoption.
JavaScript and the ECMAScript standard that underlie it historically have had an excessively large set of keywords and reserved words “inherited” from Java. ES5 partially loosened ES3‘s past keyword restrictions. For example, byte, char, and int were reserved in ES3 but aren’t in ES5.
Many years ago, before work started on ECMAScript after ES3, a few browsers stopped reserving all of ES3’s reserved words. In response browsers generally started to un-reserve many of these names. As it turned out this un-reservation went too far: ES5 un-reserved many of these words, but it didn’t un-reserve all of them. In particular, while some implementations un-reserved the names class, enum, export, extends, import, and super, ES5 did not.
Firefox un-reserved these names then along with some other browsers. But as ES5 corrects the over-reservation of ES3 without un-reserving these names, we are moving to align with ES5 by re-reserving class, enum, export, extends, import, and super in all code. (Firefox 4 reserves these names only in strict mode code.)
You can experiment with a version of Firefox with these changes by downloading a TraceMonkey nightly build. Trunk’s still locked down for Firefox 4, so it hasn’t picked up these changes just yet. (Don’t forget to use the profile manager if you want to keep the settings you use with your primary Firefox installation pristine.)
Will these words be reserved where contextually it wouldn’t matter, such as obj.import?
Which browser *didn’t* unreserve these words? Is this likely to break existing websites which have scripts coded for non-IE browsers?
Comment by Benjamin Smedberg — 16.03.11 @ 10:13
Easy, easy! We considered these things. IE and WebKit have always reserved these words, so any site that wants to work with IE won’t have used them. Only Chrome, Opera, and us ever un-reserved them. We’ll be okay — especially since I deliberately made the change early so that there’s a long lag time for extensions (the most likely transgressors, outside Mozilla-specific sites written by Mozilla people themselves) to be fixed.
obj.importand a few other contexts where keywords and reserved words are permitted by ES5 are not affected by this change. You can still dofile.delete(),var o = { class: 42 };, and so on just as you could before with any identifier even if it was a keyword or reserved word.Comment by Jeff — 16.03.11 @ 10:46
[…] and will be moving to Firefox 5, which is targeted for a late June 2011 release. Mozilla’s Jeff Walden said that the regular latest trunk builds do not include these additions, as the development tree […]
Pingback by Firefox 4.0.1 Ahead, First Firefox 5 Build, Sort Of | ConceivablyTech — 16.03.11 @ 13:32