Related
In javascript I can have, for example,
var a = 1;
while (a < 10) a++;
if (a === 10) a = 1;
So there are situations where braces are not required (though I usually put them in for clarity and to stop jshint from bothering me about their lack.)
Curiously (to me anyway) function doesn't work the same. I do
function bar(a) { return a + 1; }
but can't do
function foo(a) return bar(a);
What is so different about function that it can't behave like if and while etc?
Eliminating braces for single line statements/expressions is a common pattern across many languages.
It's just syntactic sugar for the (lazy :)) programmer.
If you have multiple statements within the if or while, you would still have to write the {} around them.
I would personally suggest always doing so because forgetting {} could lead to non-obvious bugs sometimes:
let i = 0;
if (i > 0)
i++;
console.log('this still happens');
Addition of arrow functions in ES6 allows this same behavior with functions:
Your function:
function bar(a) { return a + 1; }
Could be written without {} because it has a single expression:
const bar = a => a + 1;
But omitting {} for multiple operations would again be a bug:
let x = x => x + 1; console.log('this still happens');
You could get away with using the , operator to chain expressions:
let i = 0;
if (i > 0)
i++, // <-- notice the comma
console.log('now this does not happen');
But that arguably makes for far less readable code.
Bottom line is, using {} by default is a good choice in most cases.
It's all about syntax.
In scheme, a function maybe looks like this:
(define (square x)
(* x x))
In python, a function maybe looks like this:
def square(x):
return x * x
So, JavaScript Function Declaration Statement is:
function name_this_is_function_header(...parameters) {
// and this is function body
// statements
}
It must include a body which notation is { } . (though, ES6 add a syntax sugar for arrow function, () => { } , you can omit { } if only one statement in it, anyway)
function is a token, ( ) is a pair of tokens, { } also a pair of tokens, compiler or interpreter treat them all as a whole abstraction named JavaScript function.
JavaScript borrowed a lot syntax from Java, Java did the same thing to C++, C++ did the same thing to C ... , that's why.
For statement, such as if and while, it's syntax:
if (condition) one-statement;
while (condition) one-statement;
So, it's all about statement, statement could be single, could be compound.
Single statement don't need { }, compound statement is just several single statements included by { } tokens or notations. If you need several statements after true, you must use compound statement as a whole.
It's not about something mysterious, It's just how do you write it to express.
I read this question about the "comma operator" in expressions (,) and the MDN docs about it, but I can't think of a scenario where it is useful.
So, when is the comma operator useful?
The following is probably not very useful as you don't write it yourself, but a minifier can shrink code using the comma operator. For example:
if(x){foo();return bar()}else{return 1}
would become:
return x?(foo(),bar()):1
The ? : operator can be used now, since the comma operator (to a certain extent) allows for two statements to be written as one statement.
This is useful in that it allows for some neat compression (39 -> 24 bytes here).
I'd like to stress the fact that the comma in var a, b is not the comma operator because it doesn't exist within an expression. The comma has a special meaning in var statements. a, b in an expression would be referring to the two variables and evaluate to b, which is not the case for var a, b.
The comma operator allows you to put multiple expressions in a place where one expression is expected. The resulting value of multiple expressions separate by a comma will be the value of the last comma separated expression.
I don't personally use it very often because there aren't that many situations where more than one expression is expected and there isn't a less confusing way to write the code than using the comma operator. One interesting possibility is at the end of a for loop when you want more than one variable to be incremented:
// j is initialized to some other value
// as the for loop executes both i and j are incremented
// because the comma operator allows two statements to be put in place of one
for (var i = 0; i < items.len; i++, j++) {
// loop code here that operates on items[i]
// and sometimes uses j to access a different array
}
Here you see that i++, j++ can be put in a place where one expression is allowed. In this particular case, the multiple expressions are used for side affects so it does not matter that the compound expressions takes on the value of the last one, but there are other cases where that might actually matter.
The Comma Operator is frequently useful when writing functional code in Javascript.
Consider this code I wrote for a SPA a while back which had something like the following
const actions = _.chain(options)
.pairs() // 1
.filter(selectActions) // 2
.map(createActionPromise) // 3
.reduce((state, pair) => (state[pair[0]] = pair[1], state), {}) // 4
.value();
This was a fairly complex, but real-world scenario. Bear with me while I explain what is happening, and in the process make the case for the Comma Operator.
This uses Underscore's chaining to
Take apart all of the options passed to this function using pairs
which will turn { a: 1, b: 2} into [['a', 1], ['b', 2]]
This array of property pairs is filtered by which ones are deemed to be 'actions' in the system.
Then the second index in the array is replaced with a function that returns a promise representing that action (using map)
Finally the call to reduce will merge each "property array" (['a', 1]) back into a final object.
The end result is a transformed version of the options argument, which contains only the appropriate keys and whose values are consumable by the calling function.
Looking at just
.reduce((state, pair) => (state[pair[0]] = pair[1], state), {})
You can see the reduce function starts with an empty state object, state, and for each pair representing a key and value, the function returns the same state object after adding a property to the object corresponding to the key/value pair. Because of ECMAScript 2015's arrow function syntax, the function body is an expression, and as a result, the Comma Operator allows a concise and useful "iteratee" function.
Personally I have come across numerous cases while writing Javascript in a more functional style with ECMAScript 2015 + Arrow Functions. Having said that, before encountering arrow functions (such as at the time of the writing of the question), I'd never used the comma operator in any deliberate way.
Another use for the comma operator is to hide results you don't care about in the repl or console, purely as a convenience.
For example, if you evaluate myVariable = aWholeLotOfText in the repl or console, it will print all the data you just assigned. This might be pages and pages, and if you'd prefer not to see it, you can instead evaluate myVariable = aWholeLotOfText, 'done', and the repl/console will just print 'done'.
Oriel correctly points out† that customized toString() or get() functions might even make this useful.
Comma operator is not specific to JavaScript, it is available in other languages like C and C++. As a binary operator this is useful when the first operand, which is generally an expression, has desired side effect required by second operand. One example from wikipedia:
i = a += 2, a + b;
Obviously you can write two different lines of codes, but using comma is another option and sometimes more readable.
I'd disagree with Flanagan, and say, that comma is really useful and allows to write more readable and elegant code, especially when you know what you're doing:
Here's the greatly detailed article on comma usage:
Several examples from out from there for the proof of demonstration:
function renderCurve() {
for(var a = 1, b = 10; a*b; a++, b--) {
console.log(new Array(a*b).join('*'));
}
}
A fibonacci generator:
for (
var i=2, r=[0,1];
i<15;
r.push(r[i-1] + r[i-2]), i++
);
// 0,1,1,2,3,5,8,13,21,34,55,89,144,233,377
Find first parent element, analogue of jQuery .parent() function:
function firstAncestor(el, tagName) {
while(el = el.parentNode, el && (el.tagName != tagName.toUpperCase()));
return el;
}
//element in http://ecma262-5.com/ELS5_HTML.htm
var a = $('Section_15.1.1.2');
firstAncestor(a, 'div'); //<div class="page">
I haven't found practical use of it other than that but here is one scenario in which James Padolsey nicely uses this technique for IE detection in a while loop:
var ie = (function(){
var undef,
v = 3,
div = document.createElement('div'),
all = div.getElementsByTagName('i');
while ( // <-- notice no while body here
div.innerHTML = '<!--[if gt IE ' + (++v) + ']><i></i><![endif]-->',
all[0]
);
return v > 4 ? v : undef;
}());
These two lines must to execute :
div.innerHTML = '<!--[if gt IE ' + (++v) + ']><i></i><![endif]-->',
all[0]
And inside comma operator, both are evaluated though one could have made them separate statements somehow.
There is something "odd" that can be done in JavaScript calling a function indirectly by using the comma operator.
There is a long description here:
Indirect function call in JavaScript
By using this syntax:
(function() {
"use strict";
var global = (function () { return this || (1,eval)("this"); })();
console.log('Global === window should be true: ', global === window);
var not_global = (function () { return this })();
console.log('not_global === window should be false: ', not_global === window);
}());
You can get access to the global variable because eval works differently when called directly vs called indirectly.
I've found the comma operator most useful when writing helpers like this.
const stopPropagation = event => (event.stopPropagation(), event);
const preventDefault = event => (event.preventDefault(), event);
const both = compose(stopPropagation, preventDefault);
You could replace the comma with either an || or &&, but then you'd need to know what the function returns.
More important than that, the comma separator communicates intent -- the code doesn't care what the left-operand evaluates to, whereas the alternatives may have another reason for being there. This in turn makes it easier to understand and refactor. If the function return type ever changes, the code above would not be affected.
Naturally you can achieve the same thing in other ways, but not as succinctly. If || and && found a place in common usage, so too can the comma operator.
One typical case I end up using it is during optional argument parsing. I think it makes it both more readable and more concise so that the argument parsing doesn't dominate the function body.
/**
* #param {string} [str]
* #param {object} [obj]
* #param {Date} [date]
*/
function f(str, obj, date) {
// handle optional arguments
if (typeof str !== "string") date = obj, obj = str, str = "default";
if (obj instanceof Date) date = obj, obj = {};
if (!(date instanceof Date)) date = new Date();
// ...
}
Let's say you have an array:
arr = [];
When you push onto that array, you are rarely interested in push's return value, namely the new length of the array, but rather the array itself:
arr.push('foo') // ['foo'] seems more interesting than 1
Using the comma operator, we can push onto the array, specify the array as the last operand to comma, and then use the result -- the array itself -- for a subsequent array method call, a sort of chaining:
(arr.push('bar'), arr.push('baz'), arr).sort(); // [ 'bar', 'baz', 'foo' ]
It saves you from using return in nested conditionals and it's very handy especially with the ternary operator. Such as;
function insert(v){
return this.node > v ? this.left.size < this.right.size ? ( this.left.insert(v)
, this
)
: ( this.left.insert(this.node)
, this.node = this.right.popmin()
, this.insert(v)
, this
)
: this.left.size < this.right.size ? ( this.right.insert(this.node)
, this.node = this.left.popmax()
, this.insert(v)
, this
)
: ( this.right.insert(v)
, this
)
}
I just came across this today looking at the proposals for pipeline operator proposal and partial application...
(https://github.com/tc39/proposal-pipeline-operator
(https://github.com/tc39/proposal-partial-application#hack-style-pipelines)
Also, Hack-style pipelines are already feasible without introducing new syntax today:
let $; // Hack-style topic variable
let result = (
$= books,
$= filter($, _ => _.title = "..."),
$= map($, _ => _.author),
$);
The use of comma expressions here can kind of fake the pipeline operator that isn't in the language yet.
Eliminating the space between $= simulates the feeling of a proper pipe token, |>. Note that the "topic" variable, $, can be anything here and that it's just shorthand for repeatedly overwriting the variable. So something more akin to ...
// blocking inside an IIFE
let result = (() => {
let $;
$ = books;
$ = filter($, _ => _.title = "..."),
$ = map($, _ => _.author),
return $;
})()
The "comma" version successfully cuts out some of the noise, getting you closer to what the proposal would be:
let result = books
|> filter($, _ => _.title = "..."
|> map($, _ => _.author)
Here's another example using it to compose functions:
const double = (x) => 2 * x;
const add = (x, y) => x + y;
const boundScore = (min, max, score) => Math.max(min, Math.min(max, score));
const calculateScore = ($) => (
$= double($),
$= add($, 20),
$= boundScore(0, 100, $),
(console.log($), $)
)
const score = calculateScore(28)
The comma operator (,) evaluates each of its operands (from left to right) and returns the value of the last operand. This lets you create a compound expression in which multiple expressions are evaluated, with the compound expression's final value being the value of the rightmost of its member expressions. This is commonly used to provide multiple parameters to a for loop.
let x = 1;
x = (x++, x);
console.log(x);
// expected output: 2
x = (2, 3);
console.log(x);
// expected output: 3
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_Operator
Another area where comma operator can be used is Code Obfuscation.
Let's say a developper writes some code like this:
var foo = 'bar';
Now, she decides to obfuscate the code. The tool used may changed the code like this:
var Z0b=(45,87)>(195,3)?'bar':(54,65)>(1,0)?'':'baz';// Z0b == 'bar'
Demo: http://jsfiddle.net/uvDuE/
What is the difference between a statement and a expression? How can i know each one is?
Why void transform this:
void function() {
}();
into an expression?
And why this works:
something((something) => something + 2);
and this don't:
something((something) => if (something) { something + 2 });
?
Thanks!!
Statements and expressions are different language units. What's probably tripping you up is that JavaScript, unlike some other languages, has what the spec calls ExpressionStatement: It can treat any expression as a statement (but it cannot treat statements as expressions). So for instance, this is valid JavaScript:
flag && console.log("Hi there");
...whereas in (say) Java that wouldn't be valid, because while Java has some specific statements to allow for specific expression-like things (method calls, for instance), it doesn't have JavaScript's overall ExpressionStatement.
Why void transform this:
void function() {
}();
into an expression?
Because void is an operator. It evaluates its operand (whatever follows it), and then sets its result to undefined. It's not at all related to the void that you see in languages like C, C++, Java, or C#. So the whole thing is an ExpressionStatement. The only reason you need the void there is that without it, when the parser is expecting to see a statement, the keyword function puts the parser into a state where it's expecting a function declaration, not an expression. (You can use any operator, not just void, to put the parser into expression state; details in this question and its answers.)
And why this works:
something((something) => something + 2);
and this don't:
something((something) => if (something) { something + 2 });
Because of the way arrow functions are defined by the specification. There are two forms of arrow function:
Ones with a concise body (no {})
Ones with a verbose body
Concise example:
array.sort((a, b) => a - b);
Equivalent verbose example:
array.sort((a, b) => {
return a - b;
});
Arrow functions with concise bodies require that the body be an expression because, as you can see above, they return the result of the expression. You can't use a statement there for the same reason you can't use a statement other places an expression is required: A result value is needed for the implicit return statement. Your second example, translated to a verbose body, is this:
something((something) => {
return if (something) { something + 2 };
});
...which demonstrates why it didn't work: You have an if after return, but the return statement requires an operand (expression) or statement terminator instead.
In short, expression refers to value, statement defines behavior.
For a complete explanation you should always read the top voted answer: T.J. Crowder's answer
Let me just show you some naive examples.
The following code define a value. It is a statement called let statement led by let keyword. Here 1 is an expression.
// statement
// |---------|
let n = 1 ;
// |-|
// expression
And this is for statement led by for keyword. It comes with some nested expressions and statements.
// expression(1)
// |-----------|
for (num in numArr) { //--+
// |
sum += (num * 3); // statement(2) // |
// |-----| // |statement(1)
// expression(2) // |
// |
} //--+
So a statement is an instruction unit telling computer what to DO. for statement, while statement, if statement, they are all Actions, in another word Tasks.
But for expression, we are talking about values, valuables, objects, or some procedures that can produce a value, like function.
1 + 2
(2 + 3) * 5 === 25
new Foo()
So Javascript also has function expression. Because function is a value. In the following code,
The entire snippet is a statement.
Everything after = is an expression.
return width * height; is nested statement.
width * height is an expression.
const rectArea = function(width, height) {
return width * height;
};
I can put a return anywhere such as in a function, in an if block, case block.
How come this doesn't work:
(x == "good") ? (return("works")):"";
UPDATE: I know I can do this:
return (x == "good") ? ("works"):"";
Just want to know why the first case isn't acceptable.
It's because the grammar of a ternary operation is this:
condition ? expr1 : expr2
And a return statement isn't technically considered an expression.
Edit: here's some more info. The above explains it in terms of the grammar of the language, but here's a little bit about the reasoning of why.
I've actually dug into this before, because I've always thought it would be cool to be able to do stuff like:
someFlag && return;
Rather than
if (someFlag) return;
The problem, however, is that expressions always need to evaluate to something. This requirement is at odds with the role of the return statement, however, which along with (optionally) returning a result, also immediately terminates execution of the current function. This termination of the current function is logically inconsistent with the need to evaluate the value of the return statement itself, if it were indeed an expression.
Given that inconsistency, the language authors apparently chose to not allow return statements to act as expressions. Hope I managed to word that in a way that makes sense.
are you trying to do this:
return (x == "good") ? "works":"";
return isn't a function, so return("works") isn't correct.
alternatively you could also do:
var x = "bad";
var y = (x=="good")? "works" : "";
return y;
but this is more verbose. So to answer your question, you can put return anywhere in a function, but anything after it won't be executed. so
function x ()
{
var str = "";
return "I love puppies.";
str = "me too!" //this won't ever execute, because return exits the function.
}
The one exception to this is variable declaration, because variables are automatically declared at the beginning no matter where you put them.
function y (){
return "";
var x;
}
is really:
function y (){
var x;
return "";
}
The return keyword should come first:
return (x == "good") ? "works": "";
The reason is that return x; is a statement. You can't use (return x) as an expression.
All expressions can be used where a statement is expected, but not all statements can be used where an expression is expected.
The return keyword marks the beginning of a statement. It is not an expression, which you could use with the ternary operator.
Based off of this grammar for javascript, The ternary operator is defined as :
OrExpression ? AssignmentExpression : AssignmentExpression
Whereas return is a statement (well, the beginning of one anyways).
In any case messing with control flow in an "expressive" (read: "I want to be clever") form like ternary expressions would not be recommended by anyone I know. an if statement is the same amount of characters:
if(x==good) return x;
(x==good)?(return x)
Because "Almost everything is an expression" hasn't made it into the language yet.
Are you saying if x is "good", then return, otherwise do nothing else? In that case,
if (x == "good") return "works";
does the trick. Furthermore, return is not a function, it is a javascript token, so no parentheses should be used with return.
All the answers that begin with "return" are doing different behavior from what I think the OP intended in his ternary operation. I'm guessing the OP wants
x == "good" ? return "works" : "";
to mean
if(x == "good") {
return works;
}
else {
""; //does nothing because the statement ""; has no side effects
}
It doesn't do this because the format is
statement1 ? statement2 : statement3;
All statements may have side-effects but only the return value (in the case of statement1, just the truthiness of it) are considered by the ternary operator.
Even though the ? : is best read in terms of "if" and "then," when thinking closer to the level of syntax it should be thought of as an expression that factors into side-effects and a return value. If you understand the difference between x++ and ++x, you will be able to understand the ternary operator.
By way of example, here are some illegal statements that are illegal for the same reason.
if( (return 5) == 5) {
//...
}
if (loadUserStats(return userId)) == "FAILED") {
throw error("oops");
}
x = return y++;
I read this question about the "comma operator" in expressions (,) and the MDN docs about it, but I can't think of a scenario where it is useful.
So, when is the comma operator useful?
The following is probably not very useful as you don't write it yourself, but a minifier can shrink code using the comma operator. For example:
if(x){foo();return bar()}else{return 1}
would become:
return x?(foo(),bar()):1
The ? : operator can be used now, since the comma operator (to a certain extent) allows for two statements to be written as one statement.
This is useful in that it allows for some neat compression (39 -> 24 bytes here).
I'd like to stress the fact that the comma in var a, b is not the comma operator because it doesn't exist within an expression. The comma has a special meaning in var statements. a, b in an expression would be referring to the two variables and evaluate to b, which is not the case for var a, b.
The comma operator allows you to put multiple expressions in a place where one expression is expected. The resulting value of multiple expressions separate by a comma will be the value of the last comma separated expression.
I don't personally use it very often because there aren't that many situations where more than one expression is expected and there isn't a less confusing way to write the code than using the comma operator. One interesting possibility is at the end of a for loop when you want more than one variable to be incremented:
// j is initialized to some other value
// as the for loop executes both i and j are incremented
// because the comma operator allows two statements to be put in place of one
for (var i = 0; i < items.len; i++, j++) {
// loop code here that operates on items[i]
// and sometimes uses j to access a different array
}
Here you see that i++, j++ can be put in a place where one expression is allowed. In this particular case, the multiple expressions are used for side affects so it does not matter that the compound expressions takes on the value of the last one, but there are other cases where that might actually matter.
The Comma Operator is frequently useful when writing functional code in Javascript.
Consider this code I wrote for a SPA a while back which had something like the following
const actions = _.chain(options)
.pairs() // 1
.filter(selectActions) // 2
.map(createActionPromise) // 3
.reduce((state, pair) => (state[pair[0]] = pair[1], state), {}) // 4
.value();
This was a fairly complex, but real-world scenario. Bear with me while I explain what is happening, and in the process make the case for the Comma Operator.
This uses Underscore's chaining to
Take apart all of the options passed to this function using pairs
which will turn { a: 1, b: 2} into [['a', 1], ['b', 2]]
This array of property pairs is filtered by which ones are deemed to be 'actions' in the system.
Then the second index in the array is replaced with a function that returns a promise representing that action (using map)
Finally the call to reduce will merge each "property array" (['a', 1]) back into a final object.
The end result is a transformed version of the options argument, which contains only the appropriate keys and whose values are consumable by the calling function.
Looking at just
.reduce((state, pair) => (state[pair[0]] = pair[1], state), {})
You can see the reduce function starts with an empty state object, state, and for each pair representing a key and value, the function returns the same state object after adding a property to the object corresponding to the key/value pair. Because of ECMAScript 2015's arrow function syntax, the function body is an expression, and as a result, the Comma Operator allows a concise and useful "iteratee" function.
Personally I have come across numerous cases while writing Javascript in a more functional style with ECMAScript 2015 + Arrow Functions. Having said that, before encountering arrow functions (such as at the time of the writing of the question), I'd never used the comma operator in any deliberate way.
Another use for the comma operator is to hide results you don't care about in the repl or console, purely as a convenience.
For example, if you evaluate myVariable = aWholeLotOfText in the repl or console, it will print all the data you just assigned. This might be pages and pages, and if you'd prefer not to see it, you can instead evaluate myVariable = aWholeLotOfText, 'done', and the repl/console will just print 'done'.
Oriel correctly points out† that customized toString() or get() functions might even make this useful.
Comma operator is not specific to JavaScript, it is available in other languages like C and C++. As a binary operator this is useful when the first operand, which is generally an expression, has desired side effect required by second operand. One example from wikipedia:
i = a += 2, a + b;
Obviously you can write two different lines of codes, but using comma is another option and sometimes more readable.
I'd disagree with Flanagan, and say, that comma is really useful and allows to write more readable and elegant code, especially when you know what you're doing:
Here's the greatly detailed article on comma usage:
Several examples from out from there for the proof of demonstration:
function renderCurve() {
for(var a = 1, b = 10; a*b; a++, b--) {
console.log(new Array(a*b).join('*'));
}
}
A fibonacci generator:
for (
var i=2, r=[0,1];
i<15;
r.push(r[i-1] + r[i-2]), i++
);
// 0,1,1,2,3,5,8,13,21,34,55,89,144,233,377
Find first parent element, analogue of jQuery .parent() function:
function firstAncestor(el, tagName) {
while(el = el.parentNode, el && (el.tagName != tagName.toUpperCase()));
return el;
}
//element in http://ecma262-5.com/ELS5_HTML.htm
var a = $('Section_15.1.1.2');
firstAncestor(a, 'div'); //<div class="page">
I haven't found practical use of it other than that but here is one scenario in which James Padolsey nicely uses this technique for IE detection in a while loop:
var ie = (function(){
var undef,
v = 3,
div = document.createElement('div'),
all = div.getElementsByTagName('i');
while ( // <-- notice no while body here
div.innerHTML = '<!--[if gt IE ' + (++v) + ']><i></i><![endif]-->',
all[0]
);
return v > 4 ? v : undef;
}());
These two lines must to execute :
div.innerHTML = '<!--[if gt IE ' + (++v) + ']><i></i><![endif]-->',
all[0]
And inside comma operator, both are evaluated though one could have made them separate statements somehow.
There is something "odd" that can be done in JavaScript calling a function indirectly by using the comma operator.
There is a long description here:
Indirect function call in JavaScript
By using this syntax:
(function() {
"use strict";
var global = (function () { return this || (1,eval)("this"); })();
console.log('Global === window should be true: ', global === window);
var not_global = (function () { return this })();
console.log('not_global === window should be false: ', not_global === window);
}());
You can get access to the global variable because eval works differently when called directly vs called indirectly.
I've found the comma operator most useful when writing helpers like this.
const stopPropagation = event => (event.stopPropagation(), event);
const preventDefault = event => (event.preventDefault(), event);
const both = compose(stopPropagation, preventDefault);
You could replace the comma with either an || or &&, but then you'd need to know what the function returns.
More important than that, the comma separator communicates intent -- the code doesn't care what the left-operand evaluates to, whereas the alternatives may have another reason for being there. This in turn makes it easier to understand and refactor. If the function return type ever changes, the code above would not be affected.
Naturally you can achieve the same thing in other ways, but not as succinctly. If || and && found a place in common usage, so too can the comma operator.
One typical case I end up using it is during optional argument parsing. I think it makes it both more readable and more concise so that the argument parsing doesn't dominate the function body.
/**
* #param {string} [str]
* #param {object} [obj]
* #param {Date} [date]
*/
function f(str, obj, date) {
// handle optional arguments
if (typeof str !== "string") date = obj, obj = str, str = "default";
if (obj instanceof Date) date = obj, obj = {};
if (!(date instanceof Date)) date = new Date();
// ...
}
Let's say you have an array:
arr = [];
When you push onto that array, you are rarely interested in push's return value, namely the new length of the array, but rather the array itself:
arr.push('foo') // ['foo'] seems more interesting than 1
Using the comma operator, we can push onto the array, specify the array as the last operand to comma, and then use the result -- the array itself -- for a subsequent array method call, a sort of chaining:
(arr.push('bar'), arr.push('baz'), arr).sort(); // [ 'bar', 'baz', 'foo' ]
It saves you from using return in nested conditionals and it's very handy especially with the ternary operator. Such as;
function insert(v){
return this.node > v ? this.left.size < this.right.size ? ( this.left.insert(v)
, this
)
: ( this.left.insert(this.node)
, this.node = this.right.popmin()
, this.insert(v)
, this
)
: this.left.size < this.right.size ? ( this.right.insert(this.node)
, this.node = this.left.popmax()
, this.insert(v)
, this
)
: ( this.right.insert(v)
, this
)
}
I just came across this today looking at the proposals for pipeline operator proposal and partial application...
(https://github.com/tc39/proposal-pipeline-operator
(https://github.com/tc39/proposal-partial-application#hack-style-pipelines)
Also, Hack-style pipelines are already feasible without introducing new syntax today:
let $; // Hack-style topic variable
let result = (
$= books,
$= filter($, _ => _.title = "..."),
$= map($, _ => _.author),
$);
The use of comma expressions here can kind of fake the pipeline operator that isn't in the language yet.
Eliminating the space between $= simulates the feeling of a proper pipe token, |>. Note that the "topic" variable, $, can be anything here and that it's just shorthand for repeatedly overwriting the variable. So something more akin to ...
// blocking inside an IIFE
let result = (() => {
let $;
$ = books;
$ = filter($, _ => _.title = "..."),
$ = map($, _ => _.author),
return $;
})()
The "comma" version successfully cuts out some of the noise, getting you closer to what the proposal would be:
let result = books
|> filter($, _ => _.title = "..."
|> map($, _ => _.author)
Here's another example using it to compose functions:
const double = (x) => 2 * x;
const add = (x, y) => x + y;
const boundScore = (min, max, score) => Math.max(min, Math.min(max, score));
const calculateScore = ($) => (
$= double($),
$= add($, 20),
$= boundScore(0, 100, $),
(console.log($), $)
)
const score = calculateScore(28)
The comma operator (,) evaluates each of its operands (from left to right) and returns the value of the last operand. This lets you create a compound expression in which multiple expressions are evaluated, with the compound expression's final value being the value of the rightmost of its member expressions. This is commonly used to provide multiple parameters to a for loop.
let x = 1;
x = (x++, x);
console.log(x);
// expected output: 2
x = (2, 3);
console.log(x);
// expected output: 3
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_Operator
Another area where comma operator can be used is Code Obfuscation.
Let's say a developper writes some code like this:
var foo = 'bar';
Now, she decides to obfuscate the code. The tool used may changed the code like this:
var Z0b=(45,87)>(195,3)?'bar':(54,65)>(1,0)?'':'baz';// Z0b == 'bar'
Demo: http://jsfiddle.net/uvDuE/