Discuss
  • Iteration (was: Re: Object.values and/or Object.forEach ?)

Iteration (was: Re: Object.values and/or Object.forEach ?)

# Axel Rauschmayer (11 years ago)

Why refuse a convenient library method and force users to

  1. let values = [];
  2. for (v of values(o)) { values.push(v); } , if it can be just let values = Object.values(o);?

Note that you can do either of the following:

let values = [...values(o)]; let values = Array.from(values(o));

Thanks. I though mentioned also, there is no big need to provide some alternative fancy examples of doing some action in JS. I'm pretty sure everyone on this list know/understand how the designed methods (which are discussed on this list) work and how they can be applied in alternative ways. And I also don't wanna bikeshead on how this two lines are better than Object.values(...) from the user-level perspective.

With ES6 iteration protocols, we’ll face an interesting (and difficult) decision in the future: Should my function/method compute its results eagerly and return a data structure such as an array or should it compute its results lazily and return an iterable? Having two versions of everything doesn’t seem desirable to me and fortunately, converting a lazy iterable to an array is not too inconvenient.

I would, however, love to have a naming convention that indicates that a function/method works lazily. For example: values (eager) versus valueIter (lazy).

# Dmitry Soshnikov (11 years ago)

On Jun 8, 2013, at 10:20 PM, Axel Rauschmayer wrote:

Why refuse a convenient library method and force users to

  1. let values = [];
  2. for (v of values(o)) { values.push(v); } , if it can be just let values = Object.values(o);?

Note that you can do either of the following:

let values = [...values(o)]; let values = Array.from(values(o));

Thanks. I though mentioned also, there is no big need to provide some alternative fancy examples of doing some action in JS. I'm pretty sure everyone on this list know/understand how the designed methods (which are discussed on this list) work and how they can be applied in alternative ways. And I also don't wanna bikeshead on how this two lines are better than Object.values(...) from the user-level perspective.

With ES6 iteration protocols, we’ll face an interesting (and difficult) decision in the future: Should my function/method compute its results eagerly and return a data structure such as an array or should it compute its results lazily and return an iterable? Having two versions of everything doesn’t seem desirable to me and fortunately, converting a lazy iterable to an array is not too inconvenient.

I would, however, love to have a naming convention that indicates that a function/method works lazily. For example: values (eager) versus valueIter (lazy).

Yeah, agreed on naming convention (we have the convention at define time using a * symbol along wit the function name though). I believe the call time naming convention will be applied anyways later at user-level. (FWIW, in our local projects we call every generator method with "gen" prefix, e.g. genData in contrast with getData; with possible caching alternative naming as yieldData(...)).

As for having two versions of returning types (eager collection, lazy "gen"), yeah, also agreed, though don't see big reasons not to have both again, since we already have this in the languages as Object.keys(...). (Can you hear that question from a user: "oh, man, why they have provided Object.keys(..), but not Object.values(...)?"? I do.

Dmitry

# Axel Rauschmayer (11 years ago)

As for having two versions of returning types (eager collection, lazy "gen"), yeah, also agreed, though don't see big reasons not to have both again, since we already have this in the languages as Object.keys(...). (Can you hear that question from a user: "oh, man, why they have provided Object.keys(..), but not Object.values(...)?"? I do.

I never needed Object.values(), but the same argument applies to Object.entries().

Another thing to keep in mind: we should migrate to modules, so I’d want those kinds of utility functions to be in a module and not part of the pseudo-namespace Object.