Object.entries(), Object.values() (original) (raw)

We briefly mentioned Object.entries/Object.values the other day on list (to complement Object.keys).

Is there any concrete plan to propose these for ES6/ES7? Would filing a bug help? Or maybe just mentioning @rwaldron is enough to magically make it appear on an agenda. ;)

We briefly mentioned Object.entries/Object.values the other day on list (to complement Object.keys).

Is there any concrete plan to propose these for ES6/ES7? Would filing a bug help? Or maybe just mentioning @rwaldron is enough to magically make it appear on an agenda. ;) --scott

Le 19/03/2014 19:08, C. Scott Ananian a écrit :

We briefly mentioned Object.entries/Object.values the other day on list (to complement Object.keys).

Is there any concrete plan to propose these for ES6/ES7? Would filing a bug help? Or maybe just mentioning @rwaldron is enough to magically make it appear on an agenda. ;) You can make a PR at https://github.com/tc39/agendas Very much like I did there https://github.com/tc39/agendas/pull/27

David

C. Scott Ananian wrote:

propose these for ES6/ES7?

David's reply covers the main stuff, but on this question, let's be clear: ES6 is wrapped up and being edited and implemented. ES7 is fair game. Engines can implement both, so there's no reason to worry that you won't see Object.values or Object.entries for years in modern browsers. But we need to get it into consensus-ES7.

C. Scott Ananian wrote:

propose these for ES6/ES7?

David's reply covers the main stuff, but on this question, let's be clear: ES6 is wrapped up and being edited and implemented. ES7 is fair game. Engines can implement both, so there's no reason to worry that you won't see Object.values or Object.entries for years in modern browsers. But we need to get it into consensus-ES7.

/be

On Wed, Mar 19, 2014 at 2:08 PM, C. Scott Ananian <ecmascript at cscott.net>wrote:

Or maybe just mentioning @rwaldron is enough to magically make it appear on an agenda. ;)

I will gladly champion this for ES7.

On Wed, Mar 19, 2014 at 2:08 PM, C. Scott Ananian wrote:

We briefly mentioned Object.entries/Object.values the other day on list (to complement Object.keys).

Is there any concrete plan to propose these for ES6/ES7? Would filing a bug help? Or maybe just mentioning @rwaldron is enough to magically make it appear on an agenda. ;)

I will gladly champion this for ES7.

Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20140319/46437975/attachment.html

Won't this create a subtle false symmetry? For the collection types, "keys", "entries", and "values" return iterators, but in this case "Object.keys" would have to return an array. Does that matter?

Won't this create a subtle false symmetry? For the collection types, "keys", "entries", and "values" return iterators, but in this case "Object.keys" would have to return an array. Does that matter? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20140321/5bfe93d2/attachment.html

Hmm. It definitely affects the behavior when properties are added or removed during iteration.

Map and Set iterators are "live". But then, Map and Set iteration is fully specified and deterministic. That's not in the cards for property enumeration. So "live" iterators over object properties would, I'm sure, end up being less compatible across implementations than arrays, in those mutating cases.

Because of that, and because Object.keys already returns an array, I think Object.values and Object.entries should too.

-j

P.S. Separately, I just noticed that you can say: new Map(Object.entries(obj)). That Map constructor was designed to compose; nice to see that it works.

Hmm. It definitely affects the behavior when properties are added or removed during iteration.

Map and Set iterators are "live". But then, Map and Set iteration is fully specified and deterministic. That's not in the cards for property enumeration. So "live" iterators over object properties would, I'm sure, end up being less compatible across implementations than arrays, in those mutating cases.

Because of that, and because Object.keys already returns an array, I think Object.values and Object.entries should too.

-j

P.S. Separately, I just noticed that you can say: new Map(Object.entries(obj)). That Map constructor was designed to compose; nice to see that it works.

On Fri, Mar 21, 2014 at 8:18 AM, Kevin Smith wrote:

Won't this create a subtle false symmetry? For the collection types, "keys", "entries", and "values" return iterators, but in this case "Object.keys" would have to return an array. Does that matter?


es-discuss mailing list es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

On Fri, Mar 21, 2014 at 10:10 AM, Jason Orendorff <jason.orendorff at gmail.com> wrote:

Because of that, and because Object.keys already returns an array, I think Object.values and Object.entries should too.

I agree. This is also consistent with the arrays returned by getPropertyDescriptors and the proxy trap (which I believe was also going to be changed from an iterator to an array).

It's not an iterator, but it's still an iterable. It should work seamlessly in common cases such as new Map(Object.entries(obj)(which happens to be the use case I was thinking of in particular when I wrote the OP) and Array.from(Object.entries()) (which is pointless in itself, but we might start seeing Array.from in generic contexts to snapshot possible iterators/iterables).

On Fri, Mar 21, 2014 at 10:10 AM, Jason Orendorff <jason.orendorff at gmail.com> wrote:

Because of that, and because Object.keys already returns an array, I think Object.values and Object.entries should too.

I agree. This is also consistent with the arrays returned by getPropertyDescriptors and the proxy trap (which I believe was also going to be changed from an iterator to an array).

It's not an iterator, but it's still an iterable. It should work seamlessly in common cases such as new Map(Object.entries(obj) (which happens to be the use case I was thinking of in particular when I wrote the OP) and Array.from(Object.entries()) (which is pointless in itself, but we might start seeing Array.from in generic contexts to snapshot possible iterators/iterables). --scott

getPropertyDescriptors should not return an array at all but an object with all keys/symbols so it can be reused to defineProperties later on ... right?

'cause I don't see why getPropertyDescriptors would return an Array otherwise ..

getPropertyDescriptors should not return an array at all but an object with all keys/symbols so it can be reused to defineProperties later on ... right?

'cause I don't see why getPropertyDescriptors would return an Array otherwise ..

On Fri, Mar 21, 2014 at 8:32 AM, C. Scott Ananian wrote:

On Fri, Mar 21, 2014 at 10:10 AM, Jason Orendorff <jason.orendorff at gmail.com> wrote:

Because of that, and because Object.keys already returns an array, I think Object.values and Object.entries should too.

I agree. This is also consistent with the arrays returned by getPropertyDescriptors and the proxy trap (which I believe was also going to be changed from an iterator to an array).

It's not an iterator, but it's still an iterable. It should work seamlessly in common cases such as new Map(Object.entries(obj) (which happens to be the use case I was thinking of in particular when I wrote the OP) and Array.from(Object.entries()) (which is pointless in itself, but we might start seeing Array.from in generic contexts to snapshot possible iterators/iterables). --scott


es-discuss mailing list es-discuss at mozilla.org https://mail.mozilla.org/listinfo/es-discuss

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20140321/b2b92a37/attachment.html

The version I have on the agenda, that you wrote, returns an object. No disrespect to you, but this is irrelevant to the current thread.

On Fri, Mar 21, 2014 at 12:48 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote:

getPropertyDescriptors should not return an array at all but an object with all keys/symbols so it can be reused to defineProperties later on ... right?

'cause I don't see why getPropertyDescriptors would return an Array otherwise ..

The version I have on the agenda, that you wrote, returns an object. No disrespect to you, but this is irrelevant to the current thread.

Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20140321/714d5faf/attachment.html

the version in agenda is about getOwnPropertyDescriptors ... I thought it is relevant to not mess up too much with what same method without the Ownpart also because I don't know why, getPropertyDescriptors, would return an Array, except just as simulation of the Java meaning?

Or rephrasing: what is a list of descriptors useful for in ES7?

the version in agenda is about getOwnPropertyDescriptors ... I thought it is relevant to not mess up too much with what same method without the Own part also because I don't know why, getPropertyDescriptors, would return an Array, except just as simulation of the Java meaning?

Or rephrasing: what is a list of descriptors useful for in ES7?

On Fri, Mar 21, 2014 at 10:38 AM, Rick Waldron <waldron.rick at gmail.com>wrote:

On Fri, Mar 21, 2014 at 12:48 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote:

getPropertyDescriptors should not return an array at all but an object with all keys/symbols so it can be reused to defineProperties later on ... right?

'cause I don't see why getPropertyDescriptors would return an Array otherwise ..

The version I have on the agenda, that you wrote, returns an object. No disrespect to you, but this is irrelevant to the current thread.

Rick

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20140321/568ab778/attachment.html

also ... as side note, why this came back to me when the topic is Object.values I didn't go off topic, I just asked a clarification of a mentioned method that has nothing to do with values?

Anyway ... off the thread again, I didn't mean to bring irrelevant discussions in here ...

also ... as side note, why this came back to me when the topic is Object.values I didn't go off topic, I just asked a clarification of a mentioned method that has nothing to do with values?

Anyway ... off the thread again, I didn't mean to bring irrelevant discussions in here ... Cheers

On Fri, Mar 21, 2014 at 1:02 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote:

the version in agenda is about getOwnPropertyDescriptors ... I thought it is relevant to not mess up too much with what same method without the Own part also because I don't know why, getPropertyDescriptors, would return an Array, except just as simulation of the Java meaning?

Or rephrasing: what is a list of descriptors useful for in ES7?

On Fri, Mar 21, 2014 at 10:38 AM, Rick Waldron <waldron.rick at gmail.com>wrote:

On Fri, Mar 21, 2014 at 12:48 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote:

getPropertyDescriptors should not return an array at all but an object with all keys/symbols so it can be reused to defineProperties later on ... right?

'cause I don't see why getPropertyDescriptors would return an Array otherwise ..

The version I have on the agenda, that you wrote, returns an object. No disrespect to you, but this is irrelevant to the current thread.

Rick

-------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20140321/53155453/attachment.html

On Fri, Mar 21, 2014 at 4:02 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote:

the version in agenda is about getOwnPropertyDescriptors ... I thought it is relevant to not mess up too much with what same method without the Ownpart also because I don't know why, getPropertyDescriptors, would return an Array, except just as simulation of the Java meaning?

I just assumed getPropertyDescriptors was a mistyped. Sorry for the noise. I don't think they should deviate from each other.

On Fri, Mar 21, 2014 at 4:02 PM, Andrea Giammarchi < andrea.giammarchi at gmail.com> wrote:

the version in agenda is about getOwnPropertyDescriptors ... I thought it is relevant to not mess up too much with what same method without the Own part also because I don't know why, getPropertyDescriptors, would return an Array, except just as simulation of the Java meaning?

I just assumed getPropertyDescriptors was a mistyped. Sorry for the noise. I don't think they should deviate from each other.

Rick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20140321/4176892b/attachment.html

Sorry for the confusion. I was actually referring to [[OwnPropertyKeys]] returning an Array, as discussed previously:esdiscuss.org/topic/object-getownpropertydescriptors-o-plural#content-34

Presumably the corresponding proxy trap would change to return an Array as well.

But this is a bit off-topic for Object.entries/Object.values --- although related in the sense that the "[[OwnPropertyKeys]] returns Array" proposal also got support (and a +1 from be) on the list, but hasn't been formally added to the ES6 agenda as far as I can tell.

Sorry for the confusion. I was actually referring to [[OwnPropertyKeys]] returning an Array, as discussed previously: http://esdiscuss.org/topic/object-getownpropertydescriptors-o-plural#content-34

Presumably the corresponding proxy trap would change to return an Array as well.

But this is a bit off-topic for Object.entries/Object.values --- although related in the sense that the "[[OwnPropertyKeys]] returns Array" proposal also got support (and a +1 from be) on the list, but hasn't been formally added to the ES6 agenda as far as I can tell. --scott

Thanks for digging this up. I'll add it to the agenda.

2014-03-22 3:14 GMT+01:00 C. Scott Ananian :

Sorry for the confusion. I was actually referring to [[OwnPropertyKeys]] returning an Array, as discussed previously:

http://esdiscuss.org/topic/object-getownpropertydescriptors-o-plural#content-34

Presumably the corresponding proxy trap would change to return an Array as well.

But this is a bit off-topic for Object.entries/Object.values --- although related in the sense that the "[[OwnPropertyKeys]] returns Array" proposal also got support (and a +1 from be) on the list, but hasn't been formally added to the ES6 agenda as far as I can tell.

Thanks for digging this up. I'll add it to the agenda. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20140325/ac684563/attachment.html