Often I am writing a function that returns multiple values, such as a pair of coordinates:
function get_coords() {
return ???;
}
If I was using a language like Python, I would use a tuple:
return (x, y)
Or, in an OOP language like Java, I would create a custom coordinate class:
class Coordinates {
public int x;
public int y;
public Coordinates(x, y) {
this.x = x;
this.y = y;
}
}
Then return like this:
return new Coordinates(x, y);
On to JavaScript.
In JavaScript, we have the option of returning a simple object:
return {x: x, y: y}
or a Java-like approach, with a custom object:
return new coordinates(x, y)
Are there any reasons to use one above the other?
Doing this is the best (and verbose) option right now.
return {x: x, y: y}
Or, less verbose but cleaner
return {x, y}
The caller would have to do this to use the values
var c = get_coords();
alert(c.x + ' ' + c.y); // c.x and c.y holds the coordinates
If you care to use only single axis you could do –
alert(get_coords().x);
With the ECMAScript 6 you would be able to do destructuring (in caller).
var { x, y } = get_coords();
Too bad that we’ll have to wait quite long to use ECMAScript 6 safely in production (in a cross-browser manner).
More info on destructuring – http://fitzgeraldnick.com/weblog/50/
It depends entirely on what the calling code is expected to do with the returned coordinates. If your current code just needs direct access to the x and y properties, use the literal:
return {x: x, y: y};
Or with modern and/or transpiled JavaScript:
return { x, y };
If you need a more sophisticated return value, just change it:
return new Coordinates(x, y);
Or this:
return BuildCoordinate(x, y);
As long as the new return-value has x and y properties (or getters), your legacy code will still work.
As noted in Sayem’s answer, you can also “destructure” return values in ECMAScript 6, or if you’re using a web-aware transpiler/builder:
let { x, y } = get_coords();
Well, the both approaches are equal, since both are Objects with same properties, just different prototypes.
For the sake of simplicity, you should probably go with the first option. Or even simpler, with the array of the form [x, y].
2
Use the one that matches the meaning of your data.
My overwhelming habit is to use simple object literals like dictionaries/hashes and to use custom-prototyped-objects in an OOP manner.
Are you returning a simple collection of convenient values which will be immediately disassembled by the calling function? Then use a quick object literal.
Is your return value a thing that does and represents important conceptual stuff in your data model? Then take the time to write a constructor and make it a prototyped instance.
Sure, javascript lets us be flexible (sloppy) and clever (cryptically) by blending these ideas, but I find my code is much clearer if I stick to this rule.