4 ms·

I really like destructuring, but I worry about arrays becoming popular for multiple returns. If I'm using some other module, I really don't want to have to rem

I really like destructuring, but I worry about arrays becoming popular for multiple returns. If I'm using some other module, I really don't want to have to remember the order in which the parameters come, or be forced to check documentation or implementation to know for sure. With an object, I can use a console log or a debug break point and immediately see the key value pairs (hopefully well-named) without having to check the function implementation or docs to see in which order the authors decided to return (or yield, etc.) values. Can we just agree now not to use array destructuring as an excuse for returning multiple disparate values in an array? Or at least in only some idiomatic form? [error, value] would actually make sense to me, as it follows popular Node conventions.

Bahamut 12y ago
Using a set & objects is a better idea for that purpose than arrays.
TazeTSchnitzel 12y ago
The same argument applies to allowing multiple (positional) parameters. The solution is the same: named return values, with object restructuring.
pornel 12y ago
It's not a problem if you use objects, and the syntax is essentially the same: const {error, value} = (function(){ return {value, error}; })();
- andrewstuart2 12y ago
  Yeah, that's definitely the alternative I'm advocating for. I've seen many an ES6 blogger decide to use arrays in their examples. It's not quite so grievous in the context of a throwaway example, but for real world usage, it might be more costly to figure out a month or two down the road.
- deleted 12y ago
  [deleted]
- jrochkind1 12y ago
  What, seriously, the names of your variables matter? And this is seen as a good thing?
  - andrewstuart2 12y ago
    Absolutely they do. That's the major benefit of object orientation: named properties and methods. Otherwise, we fall into exactly the "boolean trap" that the author links away to. [1] [1] http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-t...
    - jrochkind1 12y ago
      properties and methods, yes. But I am not familiar with any other object-oriented language (is JS one now?) where the names of local variables matter. I mean, is 'local' even the right word, when the names chosen as references have semantic impact outside the local scope?
      - andrewstuart2 12y ago
        Right, they don't, and they shouldn't. If I'm not mistaken, we already agree completely. I'm saying that functions should return either primitives or objects that have properties (or keys, since in JS all objects are just hashmaps) that uphold some appropriate abstraction, completely separate from whatever the variables might have been called inside the function body. For example, the return object from some function `getDate()` might have a .year property, or .toUnix method, etc. If all I'm given is an array of arbitrarily typed values, I have solely the array indexes and values (or to go to the docs or implementation) to clue me into the semantic meaning of what was returned.
      - bzbarsky 12y ago
        I'm not sure why you think local variable names are mattering here... What's happening is that this expresion: const { error, value } = obj; where obj is an object will assign obj.error to error and obj.value to value. You could name your locals something else if you wanted, of course: const { error: myError, value: myValue } = obj; will assign obj.error to myError and obj.value to myValue. There just happens to be a shorter syntax for the common const { error: error, value: value } = obj; case.
Guthur 12y ago
Coming from Common Lisp multiple value return is usually used when there are some non essential values to return in addition to a primary value. Unless you specifically bind those non essential values are discarded. (defun foo () (values 1 :quux)) (+ (foo) (foo)) => 2 (multiple-value-bind (x y) (foo) (print y)) => :foo If you are returning an explicit aggregation like an array then it's not true multiple value return in my opinion.
tracker1 12y ago
FYI: destructuring works with object too.. var {foo, bar} = getSomeObject(); where foo and bar are properties of the result of getSomeObject

Bahamut 12y ago

Using a set & objects is a better idea for that purpose than arrays.

TazeTSchnitzel 12y ago

The same argument applies to allowing multiple (positional) parameters. The solution is the same: named return values, with object restructuring.

pornel 12y ago

It's not a problem if you use objects, and the syntax is essentially the same: const {error, value} = (function(){ return {value, error}; })();

andrewstuart2 12y ago
Yeah, that's definitely the alternative I'm advocating for. I've seen many an ES6 blogger decide to use arrays in their examples. It's not quite so grievous in the context of a throwaway example, but for real world usage, it might be more costly to figure out a month or two down the road.
deleted 12y ago
[deleted]
jrochkind1 12y ago
What, seriously, the names of your variables matter? And this is seen as a good thing?
- andrewstuart2 12y ago
  Absolutely they do. That's the major benefit of object orientation: named properties and methods. Otherwise, we fall into exactly the "boolean trap" that the author links away to. [1] [1] http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-trap.html http://ariya.ofilabs.com/2011/08/hall-of-api-shame-boolean-t...
  - jrochkind1 12y ago
    properties and methods, yes. But I am not familiar with any other object-oriented language (is JS one now?) where the names of local variables matter. I mean, is 'local' even the right word, when the names chosen as references have semantic impact outside the local scope?
    - andrewstuart2 12y ago
      Right, they don't, and they shouldn't. If I'm not mistaken, we already agree completely. I'm saying that functions should return either primitives or objects that have properties (or keys, since in JS all objects are just hashmaps) that uphold some appropriate abstraction, completely separate from whatever the variables might have been called inside the function body. For example, the return object from some function `getDate()` might have a .year property, or .toUnix method, etc. If all I'm given is an array of arbitrarily typed values, I have solely the array indexes and values (or to go to the docs or implementation) to clue me into the semantic meaning of what was returned.
    - bzbarsky 12y ago
      I'm not sure why you think local variable names are mattering here... What's happening is that this expresion: const { error, value } = obj; where obj is an object will assign obj.error to error and obj.value to value. You could name your locals something else if you wanted, of course: const { error: myError, value: myValue } = obj; will assign obj.error to myError and obj.value to myValue. There just happens to be a shorter syntax for the common const { error: error, value: value } = obj; case.

Guthur 12y ago

Coming from Common Lisp multiple value return is usually used when there are some non essential values to return in addition to a primary value. Unless you specifically bind those non essential values are discarded. (defun foo () (values 1 :quux)) (+ (foo) (foo)) => 2 (multiple-value-bind (x y) (foo) (print y)) => :foo If you are returning an explicit aggregation like an array then it's not true multiple value return in my opinion.

tracker1 12y ago

FYI: destructuring works with object too.. var {foo, bar} = getSomeObject(); where foo and bar are properties of the result of getSomeObject