-
Notifications
You must be signed in to change notification settings - Fork 26.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow reserved words for properties? #61
Comments
True. This was one of those Airbnb specific things. We support IE8 and IE8 doesn't support reserved words as property names ([source](http://kangax.github.com/es5-compat-table/#Reserved words as property names)): var obj = {
class: function(){}
};
// doesn't work in IE8
obj.class(); You can use them in IE8 if you use the subscript notation: // this works
obj['class'](); but this contradicts our style guide preference of using dot notation to access properties by name and subscript notation to access properties by variable #properties. This is another one of those preference decisions where it might sound like "you can't use reserved words as property names" but really what we're trying to say is "we would prefer if you didn't...for now". Maybe it would be helpful to note what the reserved and future reserved words are and explain that they can be used as Identifiers but not as an IdentifierName ES5 #7.6.1 in [supporting browsers](http://kangax.github.com/es5-compat-table/#Reserved words as property names). // SyntaxError: unexpected reserved word
function class(){} |
This is also not supported in IE7, such as |
Note that this isn't an "IE bug". It's not supported in old IE because IE's JScript engine correctly follows the ECMAScript 3 specification in this regard; which explicitly defines This was not by design, but at the time merely to document the status quo of different browsers and to ensure consistency. Other browser's engines had this behaviour as well. Since property names leave no ambiguity with other operators, this useless restriction was removed in ES5 where I'd recommend using something like JSHint (and set option |
considering most people use Babel.js now (does Airbnb?), maybe this can be rescinded. It will automatically transpile |
Yeah this can be updated. |
In 53b4173 we removed the ES5 guide which contains a lot of guidelines that are no longer very relevant for us. Similarly, some folks have raised the relevance of these rules about reserved words, given that we are now living in an age where ES3 support has mostly waned and transpilers such as Babel are widely adopted and pave over these issues. This seems like a good opportunity to simplify. Fixes #61
In 53b4173 we removed the ES5 guide which contains a lot of guidelines that are no longer very relevant for us. Similarly, some folks have raised the relevance of these rules about reserved words, given that we are now living in an age where ES3 support has mostly waned and transpilers such as Babel are widely adopted and pave over these issues. This seems like a good opportunity to simplify. Fixes airbnb#61
In 53b4173 we removed the ES5 guide which contains a lot of guidelines that are no longer very relevant for us. Similarly, some folks have raised the relevance of these rules about reserved words, given that we are now living in an age where ES3 support has mostly waned and transpilers such as Babel are widely adopted and pave over these issues. This seems like a good opportunity to simplify. Fixes airbnb#61
Under Objects it says you shouldn't use reserved words. I'm not sure this is important, though avoiding them might make sense for readability. At least using
klass
instead ofclass
would seem wrong to me, as you are corrupting a word instead of finding a readable synonym (liketype
).Right now you can use just about anything. E.g.,
test = {function: 1}; test.function === 1
–but additionally I think we can be confident this will continue to be the case. IndexedDB uses the methodcursor.continue()
which isn't just a future-protected reserved word (likeclass
) but a reserved word right now. But IndexedDB represents current API design by people involved in the standardization process.I think it's questionable from a readability point of view to use current keywords, but I don't see any reason at all to avoid words reserved for possible future use (
class
andprivate
, as used in the example, are both examples of that).The text was updated successfully, but these errors were encountered: