Discuss
  • Object.entries in 2015

Object.entries in 2015

# Leon Arnott (10 years ago)

Revisiting discussion here, here and there, I'm wondering what the status of Object.entries and Object.values is. Specifically:

  • Has a strawman Gist been made for them yet?
  • Is there any desire to make matching Reflect.ownEntries or Reflect.ownValues methods (that also provide non-enumerable and/or symbol-keyed entries) as counterparts? (Is there consensus on whether Reflect is "allowed" to have methods that aren't Proxy trap methods or exposures of essential internal methods?)
  • Related to the primary use-case of Object.entries (obtaining key/value pairs), has anyone yet proposed a Map.from method which takes plain objects, as a shorthand for new Map(Object.entries(obj)) ? (I'm still not sure whether Array.from was intended to set a precedent for future from methods, or meant solely as ES5 migration sugar).
# Leon Arnott (10 years ago)

The Map constructor takes an iterable of [key, value] pairs. Array.from takes an iterable of elements.This asymmetry is presumably because the Array constructor's behaviour is already defined. A hypothetical Map.from would merely be the same as the Map constructor!

Not quite true: Array.from, unlike every other iterable consumer in the spec, also takes array-like plain objects: Array.from({0:'E', 1:'S', 2:'6', length:3}) produces ["E","S","6"]. The motivation for Map.from is that you could feed it a "map-like object" (that is, an object with no iterator) and get a Map in return: Map.from({ foo: 1, bar: 2 }) would behave as new Map([['foo',1],['bar',2]]).

# Jordan Harband (10 years ago)

The other motivation might be subclasses - MyArray.from creates a MyArray, MyMap.from would create a MyMap.