Using reserved words as property names, revisited
JavascriptJsonPropertiesJavascript ObjectsReserved WordsJavascript Problem Overview
Can a reserved word be used as an object's property name?
This issue was raised indirectly in a previous Stack Overflow question: https://stackoverflow.com/questions/5306315/browser-support-for-using-a-reserved-word-as-a-property-name-in-javascript. The answer seemed general consensus by Alex Wayne:
> You can use those words, but only as strings and not shorthand > properties. > > foo['class']; // cool > foo.class; // not cool
While I think that they are probably more knowledgeable than me in this area and it is probably a bad idea to use reserved words in some situations, I think their conclusion is wrong based on two points:
-
testing of the reserved words using them as a "shorthand" properties
-
the HTMLFormElement makes it impossible not to use reserved words in "shorthand"
First, using the reserved word list, each was added as a property to an Object and HTMLElement, both as obj["word"] and obj.word, and then retrieved as obj["word"] and obj.word. In each of the 63 cases all eight tests worked correctly.
Second, the HTMLFormElement necessitates this works because it retrieves in its elements using shorthand notation. If <input name='typeof' value='scalar' /> is an element of a form, then form.typeof == "scalar".
From my experience, reserved words are usually data inflicted (e.g. a column named "private"), not program inflicted. As such they contaminate JSON objects, and from there input, and from there the HTMLFormElement. Simply put, without a huge amount of (IMHO unnecessary) work, it's impossible to keep reserved words not being forced to work correctly in shorthand.
It seems to me these real problems:
-
care needs to be taken not to conflict with existent properties, not reserved words
-
(many if not all) variables cannot be reserved words
-
use of reserved words as properties can be (but are not necessarily) confusing
Is this conclusion correct then, that reserved words as property names, and accessing them either as strings or shorthand, is just fine - as long as a little common sense is applied to the situation?
Javascript Solutions
Solution 1 - Javascript
In ECMAScript, starting from ES5, reserved words may be used as object property names "in the buff". This means that they don't need to be "clothed" in quotes when defining object literals, and they can be dereferenced (for accessing, assigning, and deleting) on objects without having to use square bracket indexing notation.
That said, reserved words may still NOT be used as identifier names. This is stated quite unambiguously in the spec and is stated somewhat emphatically here (if you don't want your eyes to bleed by having to read the actual language spec)...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Reserved_Words
> The following are keywords and may not be used as variables, > functions, methods, or object identifiers, because ECMAScript > specifies special behavior for them:
Solution 2 - Javascript
I'm not quite sure what the point is you want to make, so the only answer I can give is: Yes, it's ok to use reserved words as property names.
(However two small remarks: foo["class"] is ok, not foo[class]. And any way you should be using form.elements["xyz"] and not form.xyz to access an element named xyz.)
Solution 3 - Javascript
Yes, it can be used.
Just small remark, if you use YUI compressor you have to put property name which is equal to one of js reserved words in quotes.
For example, this won't compress
var a = { case : "foo"}; // syntax error, "invalid property id"
a.for = "bar"; // syntax error, "missing name after . operator"
This will do
var a = { "case" : "foo"}; //OK
a["for"] = "bar"; //OK
Here is Online JavaScript/CSS Compression Using YUI Compressor where this can be tested.
Solution 4 - Javascript
Yes, in most browsers (including IE9+)
There's actually an entry in the Kangax compatibility table for "Reserved words as property names"