I was expecting JavaScript to reject objects with duplicated properties as invalid but it accepts them in some cases.
{"a":4,"a":5} results in an SyntaxError at least in Firefox and Chrome which seems obvious due to the property a being defined twice.
However ({"a":4,"a":5}) evaluates just fine and results in an object {"a":5} in both Firefox and Chrome.
Why is the expression with the parenthesis accepted?
Summing up the responses: The first example is simply not the construction of an object but a block of labeled statements. Duplicated properities in objects are perfectly valid in which case the last definition wins.
Thanks a lot for your answers!
It is perfectly legal in ECMAScript 3 to declare duplicate properties in an object literal; the SyntaxError you get probably comes from the fact that you used an object literal as a statement, which is not possible due to the confusion with block statements ({ doSomething(); }).
If you want this to be reported as an error, you may want to switch to ECMAScript 5's strict mode: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Functions_and_function_scope/Strict_mode.
What you state has no problem if you assign it to a variable, if you don't however, you get the error you mention. Which makes all the difference from a syntax point of view.
When you wrap any structure in parens you are causing that syntax to be evaluated as an expression, the result of which is stored as a temporary variable. The error I get when not doing so in Firefox is unexpected label or invalid label, so it seems without assignment, or parens, this object construction is not treated as an object construction - instead it is treated as a block with multiple label statements that are defined illegally:
{
a: function(){
alert('a');
},
b: function(){
alert('b');
}
}
The above should be totally acceptable as an object, however you get a similar error if you evaluate it without assinging it to some form of variable, or evaluating it with parens. Put simply the duplication of the attribute name is not causing the error :)
Basically imagine your first example, but like this:
function (){
"a": 4,
"b": 5
}
That is roughly how these browsers are treating it, which is now obviously illegal javascript syntax... whereas it wasn't so obvious before.
In the first notation (parentheses-less) the javascript syntax is ambiguous. From ecmascript specification:
An ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block.
A block basically evaluates all the statements inside, equivalent to evaluating "a":4,"a":5 which is not valid JS and, in fact, returns the same SyntaxError Unexpected token :
Wrapping that code in parentheses (or, rather, a grouping operator) removes that ambiguity since an assignment expression cannot be followed by a block statement:
var test = {"a":"a","a":"b"}; //test.a === "b"
Furthermore this ambiguity can be removed by any operator or expression that cannot be used with a block statement. A practical scenario hardly comes to mind, maybe if you wanted to return an object literal as part of a conditional operator?
//this *could* come out of a JS minifier:
return x ? (foo(),{"a":"b"}) : (bar(), {"b":"a"});
Why should it not be accepted? You're simply overwriting the values. I think it's rather a feature, than an error. And it works fine for me on various browsers: http://jsbin.com/oculon/1/edit
It's like writing
var a;
a = 4;
a = 5;
alert(a);
it's not Error you just overwrite value with another
I'm guessing (though not certain) that this evaluates as an error because of the difference between the way Firefox and Chrome's JS parsers treat statements and expressions. So because it's wrapped in parentheses the second time, it's considered an expression. Since it's looking for less information in an expression, it can ignore erroneous values. You'll see that if you do...
var a = {'a': 5, 'a': 4};
console.log(a);
It works fine! And also notice that here it's in the right hand side of the statement, giving a hint that it's an expression.
Related
var a = [1, 2, 3, 4];
var b = [10, 20, 30, 40];
console.log([a, b].length)
[a, b].some(function(x) {
x.push(x.shift())
});
I was extremely surprised today when this code caused
[a,b].some(function(x){ x.push(x.shift()) });
^
TypeError: Cannot call method 'some' of undefined
Obviously the JavaScript 'auto semicolon insertion' is not working as expected here. But why?
I know you might recommend to use ; everywhere to avoid something like that, but the question is not about whether it is better to use ; or not. I would love to know what exactly happens here?
When I'm worried about semicolon insertion, I think about what the lines in question would look like without any whitespace between them. In your case, that would be:
console.log([a,b].length)[a,b].some(function(x){ etc });
Here you're telling the Javascript engine to call console.log with the length of [a,b], then to look at index [a,b] of the result of that call.
console.log returns a string, so your code will attempt to find property b of that string, which is undefined, and the call to undefined.some() fails.
It's interesting to note that str[a,b] will resolve to str[b] assuming str is a string. As Kamil points out, a,b is a valid Javascript expression, and the result of that expression is simply b.
In general, one could say that implicit semi-colon's can easily fail when defining an array on a new line, because an array defined on a new line is interpreted as a property access of the value of the expression on the previous line.
Javascript does only consider new lines to mark the end of a statement if not ending the statement after this new line would cause a parse error. See What are the rules for JavaScript's automatic semicolon insertion (ASI)? and EcmaScript 5 spec for the exact rules. (Thanks to Rob W and limelights)
What happens is the following:
The code get interpreted as
console.log([a,b].length)[a,b].some(function(x){ x.push(x.shift()) });
i.e. all as one statement.
Now parse the statement:
some is called on the value of console.log([a,b].length)[a,b]
the value of console.log([a,b].length)[a,b] is computed by taking the returned value of console.log([a,b].length) (undefined) and then trying to access the property with the name of the value of a,b.
a,b evaluates to the value of b (try it in your console). There's no property with the value of b of undefined, so the resulting value will be undefined as well.
There's no method some on undefined, hence the error.
JavaScript doesn't treat every line break as a semicolon. It usually treats line
breaks as semicolons only if it can’t parse the code without the semicolons. Basically, JavaScript treats a line break as a semicolon if the next non-space character cannot be interpreted as a continuation of the current statement. JavaScript - The Definitive Guide: 6th Ed. section 2.4
So, in your case, it is interpreting the line as something like
console.log([a,b].length)[a,b].some(function(x){ x.push(x.shift()) });
And that is the reason for error. JavaScript is trying to perform array-access on the results of console.log([a,b].length). Depending on the JavaScript engine and the return value of console.log, you might get different errors.
If it is the last statement of the function or flow, you can avoid ';' but it is recommended to put ';' at the end of the each statement to avoid such error.
I played around in the Chrome console and wondered why this statement throws a syntax error:
{}.hasOwnProperty('id');
My expectation was the return value false.
A syntax error also occurs in Firefox and IE .
The same works if I use an empty array instead of an empty object.
The same also works if I put braces around:
({}.hasOwnProperty('id'));
There's syntax ambiguity in snippet in question. Curly braces in JavaScript have two meanings: they are used to delimit code blocks, for example:
if (x) {
...
}
and they are used to declare object literals:
var obj = {
prop: "value"
}
Constext is used to differentiate between the two interpretations, and in case of:
{}.hasOwnProperty('id');
braces are resolved to block declaration, so this yields syntax error. On the other hand:
({}.hasOwnProperty('id'));
One cannot declare block inside parentheses, so {} is recognized as object literal in this context.
{} is treated as a statement block rather than an object, as you are expecting. Hence the error.
EDIT: As #Cerbrus mentioned in the comments, ({}).hasOwnProperty('id'); would return false and not an error. This is because when surrounding {} with parenthesis, it is interpreted as an Object.
JSHint give the following error:
Expected an assignment or function call and instead saw an expression.
For the following line of code:
(aFunctionOrNull) ? aFunctionOrNull() : someObject.someMethod();
It highlights the final ) on someMethod so I assume the error is there. The code works and JSHint doesn't have a problem when I change it to if () {} else {} syntax. I don't mind the longer syntax but I'd like to learn why JSHint says this and if this is a bad practice.
The biggest piece of confusion may come from the terminology. Is someObject.someMethod() not a function call?
Well, in general it's considered bad practice to call a function using the ternary operator(s), without assigning the return value (which is what you seem to be doing).Also, it could be worth checking what JSHint has to say about the following code:
(aFunctionOrNull || someObject.someMethod)();
If aFunctionOrNull is undefined (or null, or falsy), the logical-or-bit will cause the expression to evaluate to someObject.someMethod, and the resulting value of that is invoked (a reference to a function object, hopefully). This gives you the opportunity to write your code more "fail-safe" without the bulk of a nested ternary:
(aFunctionOrNull || someObject.someMethod || function(){})();
The grouped expression is now bound to evaluate to a truthy value, so no errors are thrown there.
To avoid JSHint nagging about your not doing anything with the return value, either assign it to a variable (which I don't really like doing), or add a little operator to the mix:
~(aFunctionOrNull || someObject.someMethod || function(){})();//bitwise not
!(aFunctionOrNull || someObject.someMethod || function(){})();//logical not, doesn't really matter which one
On your last question: someObject.someMethod is indeed a function call. More specifically, it's a call to a function object in the someObject's context.
For those who don't know this: JS functions are objects, and the called context is either explicitly set using the bind method (defined on the Function.prototype) or ad-hoc:
var referenceToMethod = someObject.someMethod;
referenceToMethod();//<-- inside the function objects, this now points to the global object
An easy way to think of it is that JS functions just float around aimlessly in memory/space/time, until they are called via a reference, the context of that reference is then passed to the function object, to determine what object it'll interact with. This is, sadly, the global object by default, or null in strict mode.
JSHint says about expressions, or expr:
This option suppresses warnings about the use of expressions where
normally you would expect to see assignments or function calls. Most
of the time, such code is a typo. However, it is not forbidden by the
spec and that's why this warning is optional.
While JSLint says:
An expression statement is expected to be an assignment or a
function/method call or delete. All other expression statements are
considered to be errors.
AFAIK, there's no problem in doing what you're doing only that it will issue a warning because it would expect you to use an if..else statement, but you can turn this off in JSHint with:
/*jshint expr:true */
There error is because a ternary is an expression. You could use it to set a variable:
var result = a ? b : c;
Notice that the ternary evaluates to either b or c. It's an expression.
That said, the warning (I believe) comes from the notion that ternaries suffer poorer readability than an if...else block. The code above can be rewritten
var result;
if (a) {
result = b;
} else {
result = c;
}
Which is easier to read than a ternary. JSHint does as much to promote readable code as it does valid code. If you're comfortable including these expressions in your code, go ahead and disable the warnings for expressions. (It's what I would do.)
var test=(a=1,[b=2]["sort"])();
This code works in Firefox resulting test=window (window object),
Is it valid JavaScript code? (I failed to find it in JavaScript references)
It's "valid" but looks completely pathological to me. From the name of the var, I'd guess someone came up with this as a feature test at some point, but failed to add a comment explaining why.
So here's what it's doing. First, the two assignments will resolve to the assigned value, so we can replace them (they do assign variables, which is a side effect, but that doesn't affect the evaluation of this expression):
var test=(1, [2]["sort"])();
["sort"] is just .sort:
var test=(1, [2].sort)();
The comma operator will return the last value in the brackets, so we can lose that 1:
var test=([2].sort)();
So now the bracketed part is creating an array with the number 2 in it, and finding the sort method of that array. It then calls that method, but because of the first set of brackets it calls it without a specified context.
In non-strict mode, a function called with no context gets window as its this.
So it tries to sort window and returns the result, which is window, as you saw.
In strict mode, which the JS consoles in Firebug and Chrome are, functions called without context get undefined as their this, which means this example throws an error, as mplungjan noted above. https://developer.mozilla.org/en/JavaScript/Strict_mode
I would expect that code to give an error.
The comma basically evaluates the expression on the left, a=1 and then the expression on the right [b=2]["sort"] and returns the result of the expression on the right.
a=1 sets a to 1, creating a as a global if it's not in the current scope.
[b=2] sets b to 2, creating b as a global if it's not in the current scope, and also creates a one-element array with the value 2.
[b=2]["sort"] returns the array .sort method (it does not call the method).
So the result of the expression in parentheses is the array .sort method which is then executed by the final (), and the result would be assigned to test except that it doesn't work because by then it is not actually called on an array.
The final assignment is the equivalent of this: var test = ([2].sort)();.
Can you please tell me the reason for this specific syntax structure
eval('(' + jsonString+ ')')
When parsing json text. Crockford says "The text must be wrapped in parens to avoid tripping on an ambiguity in JavaScript's syntax." here. What does that mean?
Can we avoid it?
The syntax ambiguity to which Crockford refers is that if an open curly brace is not found on expression context, it will be recognized like a block, and not like the start of an object literal.
For example:
{"foo": "bar"} // SyntaxError
Will give you a syntax error, because it will be interpreted as a block, with a string literal "foo", and a unexpected usage of the token :.
On the other hand, the parentheses, formally called the grouping operator, can only evaluate expressions, therefore we will not have any syntax ambiguity because a block can only be expected on a statement context.
({"foo": "bar"})
Edit: #el.pescado makes an interesting question:
Can you explain why eval('{}') is undefined?
ECMAScript describes an internal type to explain the behavior of statements, it's called The Completion Specification Type.
Values of the Completion type are triples of the form of (type, value, target), where type can be normal, break, continue, return, or throw.
value can be any language value or empty, and target any Identifier or empty.
An empty block (the production Block : {}) explicitly returns the following completion:
Return (normal, empty, empty).
The eval function, after executing the code, and exiting the newly created execution context, checks the result completion of the evaluated code, and in the Step 7 we can see that undefined is explicitly returned if the completion type is normal and the completion value is empty:
...
7- If result.type is normal and its completion value is empty, then return the value undefined.
...
An object literal needs to be wrapped in parentheses to properly be evaluated in eval context and other contexts:
eval('{}') is undefined, for example. whereas eval('(' + '{}' + ')' ) evaluates to Object.
If you tried this in the console, for example: {"foo":"bar"} it would throw an invalid label at you. Wrap it in parentheses and it becomes a valid expression.
#el.pescado, the string after executed by eval should be javascript understandable.
i.e if you are assigning the above string to the varible as follows
eval(' var foo1 = {"foo" : "bar"}');
foo1.foo will return bar
so, my assumption is, as there is no statement like that starts with "{" in javascript, it is throwing the error.