# Is it too late to fix \`Object.entries\` ??? **URL:** \ **Category:** đź’ˇ Ideas\ **Tags:** proposal\ **Created:** [July 25, 2022, 12:59pm UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407 "2022-07-25T12:59:00Z")\ **Posts on this page:** 10\ **Page:** 2
**Author:** ![ljharb](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ljharb/32/8_2.png) [@ljharb](https://es.discourse.group/u/ljharb)\ **Post date:** [July 26, 2022, 9:47am UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/21 "2022-07-26T09:47:42Z")
I’m not sure what you mean - you’d lose the getter/setter kind and only deal in enumerable regardless (except for the gOPDs technique mentioned earlier). I think the point about fromEntries and non-string keys is that symmetry already doesn’t exist in other ways, so it’s not a strong argument that Object.entries lacks a symmetry that shouldn’t be expected. Reflect.ownEntries would definitely convert all accessor properties to data properties, altho it would include non-enumerables as well - but passing that into fromEntries would leave everything enumerable. Again, `Object.entries(o, { symbols: true })` or similar is perfectly viable - as long as the same options bag worked on Object.keys and Object.values - but the convincing argument that needs to be made to the wider committee is that the use cases for needing this (versus existing workarounds, including `Object.entries(o).concat(Object.getOwnPropertySymbols(o).map(s => [s, o[s]])`) ---
**Author:** ![WebReflection](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/webreflection/32/248_2.png) [@WebReflection](https://es.discourse.group/u/WebReflection)\ **Post date:** [July 26, 2022, 10:01am UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/22 "2022-07-26T10:01:13Z")
> [@ljharb](#): > > Object.entries lacks a symmetry that shouldn’t be expected why is that? the name is `entries` and its revival method is called `fromEntries` ... what's expected is that if latter, born to deal with _entries_, don't discard _symbols_, it's not clear why `entries` should by default discard these ... `keys` and `values` _might_ need an update too, but `keys` is legacy and I expect more breaking possibilities there ... `Object.entries` is fresh new, and it's the only with a `Object.fromEntries` counterpart. About workarounds, it misses the point ... there are always workaround and user-land code in JS to solve lack of APIs or shenanigans, here I was trying to propose fixing one of these. ---
**Author:** ![ljharb](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ljharb/32/8_2.png) [@ljharb](https://es.discourse.group/u/ljharb)\ **Post date:** [July 26, 2022, 10:15am UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/23 "2022-07-26T10:15:25Z")
It’s been shipping since 2016; it’s not new at all - and fromEntries since 2019. Again, “it’s not the same” isn’t a compelling argument - you’d need to come up with one if you hope to have the wider committee accept the idea. ---
**Author:** ![WebReflection](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/webreflection/32/248_2.png) [@WebReflection](https://es.discourse.group/u/WebReflection)\ **Post date:** [July 26, 2022, 10:35am UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/24 "2022-07-26T10:35:03Z")
> [@ljharb](#): > > It’s been shipping since 2016; it’s not new at all - and fromEntries since 2019. it's only with IE out of the window that people stopped transpiling targeting ES5 so, as native method that doesn't get transpiled, it's relatively new, used _as is_ instead of via polyfills, that's what I meant. If adding an extra argument as option with `{symbols: true}` to have it usable in a chain of `fromEntries(entries(obj, {symbols. true}))` is not interesting and keeping it fully asymmetric and footgun prone due data/key lost is what everyone wants then I am OK, but there shouldn't be a need for huge reasons when logic and nicer DX is on the plate at the cost of ... pretty much nothing, as this would be an easy-peasy fix to the otherwise ugly API that `entries` is, compared to `fromEntries`. ---
**Author:** ![theScottyJam](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/thescottyjam/32/616_2.png) [@theScottyJam](https://es.discourse.group/u/theScottyJam)\ **Post date:** [July 26, 2022, 1:42pm UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/25 "2022-07-26T13:42:20Z")
@WebReflection - it was previously mentioned that we loose getter/setter information as well, and I'm not sure that was responded to. Should we also add stuff to preserve getters and setters, so we don't break symmetry there? Currently, if you do this, your final object is going to end up different from your original one. ```javascript Object.fromEntries(Object.entries({ get randValue() { return Math.random() } })) ``` This is also symmetry breaking, and it's also causing information loss. Is this not important as well? What about the object's prototype? Should we somehow preserve that? We're also breaking symmetry by making the resulting value not have the same prototype as the original. Perhaps we need to upgrade the meaning of "entries" to be something like `{ originalPrototype: ..., fields: [...] }`. And, what about private properties? There's no practical way to preserve those. And, what about proxies? And, as previously mentioned, how do we preserve if the property was set to be non-innumerable, or non-writtable? I believe this is why people keep saying that "broken symmetry" isn't a very strong argument - there's broken symmetry all over the place, in both directions, and there's all sorts of information being lost during this. I don't believe `Object.entries()` was ever intended to preserve every quality of the passed-in object so you could reconstruct it just as it was before, because that's simply not possible. The closest you can get to that goal is probably `Object.getOwnPropertyDescriptor()`, but even that is lossy. So, why is it so important to preserve broken symmetry related to symbols, but all of this other broken symmetry and lost information is ok? What is it about the symmetry of symbols that's special while all of these other broken symmetries can be ignored? ---
**Author:** ![WebReflection](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/webreflection/32/248_2.png) [@WebReflection](https://es.discourse.group/u/WebReflection)\ **Post date:** [July 26, 2022, 2:31pm UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/26 "2022-07-26T14:31:33Z")
> [@theScottyJam](#): > > This is also symmetry breaking It's not by the definition of _entries_ which is, currently, a list of key/value pairs. The symmetry is not about the original object, it's about original object own enumerable properties: `fromEntries` accepts symbols too, `entries` ignore symbols instead. configurable, writable, get, set, proxies, all unnecessary and unintended topics for this post, so I am not commenting these, because I've never proposed to change everything, I've just suggestd to **fix** `Object.entries`. ---
**Author:** ![theScottyJam](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/thescottyjam/32/616_2.png) [@theScottyJam](https://es.discourse.group/u/theScottyJam)\ **Post date:** [July 26, 2022, 3:00pm UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/27 "2022-07-26T15:00:33Z")
> [@WebReflection](#): > > It's not by the definition of _entries_ which is, current, a list of key/value pairs. Why is this the definition though? Couldn't we equivalently define entries as just being the object's string keys and values, and so it's `fromEntries()` that's the one at fault? And to fix it, we should provide an optional parameter to `fromEntries()` to make it so doesn't accept tuples containing symbol keys? (I know I brought that one up before, but I don't think I got a clear answer as to why you would feel that this fix isn't the right one to do to fix the symmetry, unless you do think this is a valid solution?) I understand you didn't intend to bring in all of these other subjects, but they're naturally brought in since they all deal with different forms of symmetry breaking, which is why it's important to contrast those forms of symmetry breaking with what you're describing here. I don't expect that you'd actually want to fix the symmetry in those other areas, but I do want to use them to understand why this form of symmetry matters while the others don't - which you gave a good answer to solve most of them - it's because you feel those fall outside the definition of "entries". I'm just left with one more question that I asked above. ---
**Author:** ![WebReflection](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/webreflection/32/248_2.png) [@WebReflection](https://es.discourse.group/u/WebReflection)\ **Post date:** [July 26, 2022, 3:22pm UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/28 "2022-07-26T15:22:44Z")
I have already answered to everything you are asking: 1. I have proposed (read the topic title) to fix `Object.entries`, not the entirity of JS 2. entries with numbers as key used in `fromEntries` produces the _exact same object_ entries with those numbers as string do ... nothing to fix for **developers** 3. I have zero interest in talking about all places where JS is not symmetric, my goal here was to fix _yet another one_ for consistency of serialization sake, already described that currently fails while JSON wouldn't I also have very limited time so if your goal is to let me say "_oh yeah, JS is not symmetric in many places, why even bothering fixing in a single argument one of those cases?_" you are in bad luck because that's not how I personally write code or propose changes ... it doesn't have to be a new API or nothing, that's TC39 choice, and JS is what it is because tiny incremental changes and updates are **clearly** not welcomed, as this thread proofs. Everyone is like "_yeah, we coudl do that ... but we won't!_" ... thanks, bye I guess, we can close this conversation. ---
**Author:** ![theScottyJam](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/thescottyjam/32/616_2.png) [@theScottyJam](https://es.discourse.group/u/theScottyJam)\ **Post date:** [July 26, 2022, 5:24pm UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/29 "2022-07-26T17:24:49Z")
Sorry, my intention is not to offend or to state "oh yeah, JS is not symmetric in many places, why even bothering fixing in a single argument one of those cases?" I'm not trying to downplay your feature request at all or state that it's not needed. I don't think anyone here was trying to do that. We're just wanting to understand where you're coming from. So, please forgive me if that's what the repeated questions felt like, but it's difficult to start talking about how to fix a broken feature if we aren't on the same page about what's broken in the first place, and I was having difficulty understanding what you felt was broken. You recently clarified for me many points (specifically, the only broken symmetry you were worried about, were issues that conflicted with your intuitive understanding of what an "entry" was). Really, the only question I had left was why, if broken symmetry really is the root issue, couldn't we also consider fixing Object.fromEntries() instead of Object.entries()? I assume you will say no to this, but if you don't like this solution, why not? As far as I can tell, this is an equally valid solution to fix broken symmetry, unless there's more to the definition of "symmetry" that hasn't been communicated yet. Before fixing something, we have to understand what is broken. And it takes a bit of patience and time to really get to the bottom of things sometimes. But, if you want to be done, we can be done. ---
**Author:** ![WebReflection](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/webreflection/32/248_2.png) [@WebReflection](https://es.discourse.group/u/WebReflection)\ **Post date:** [July 26, 2022, 5:55pm UTC](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407/30 "2022-07-26T17:55:14Z")
> [@theScottyJam](#): > > I don't think anyone here was trying to do that. We're just wanting to understand where you're coming from I am coming from times where [entries were cool for a Map.from proposal too](https://esdiscuss.org/topic/object-entries-in-2015) to then realize the produced array never includes all own enumerable properties, just a subset, because _keys_ was taken into account, but then `fromEntries` didn't take anything previously discussed into account (and rightly so ... we should move forward, not backward, like `entries` did). In a chain of `entries` and `fromEntries` I've lost data for no reason and that's because the two methods do different things with _entries_ ... `fromEntries` does the **right** thing, while _entries_ is stuck with Chrome 5 and _Object.keys_ in times _symbols_ didn't even exist. I hope `Reflect.entries` and `Reflect.fromEntries` would fix this somehow, but that's whole new proposal that takes forever to land as usual ... so here I was hoping for a quick fix over an already well known and used API. > [@theScottyJam](#): > > couldn't we also consider fixing Object.fromEntries() instead of Object.entries()? `Object.fromEntries` is not broken for modern JS, `Object.entries` is ... because it doesn't understand modern JS, like _symbols_. > [@theScottyJam](#): > > Before fixing something, we have to understand what is broken Everyone on twitter istantly understood what is broken by reading [my very first example](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407) ... it's exhausting in here every single time, reason I'm fading out more than ever these days. It's tiresome to hear every time the same answer: "_yeah, we got it, but not compelling enough_" ... with all changes landing just because big company asked for it it's not clear to me anymore what's this space about ... nothing passes through, even small things that everyone agrees are doable become a week of discussions with repeated answers over and over. Apologies for the rant but really there should be a _manifest_ about all conversations that won't need to even start becuse if it's not big money company asking for it or a TC39 member itself, it's not interesting and it's not going to happen. In this thread people suggested me `Object.getOwnPropertyDescriptrs` which is something [I've brought to JS in times people listened to developers](https://esdiscuss.org/topic/object-getownpropertydescriptors-o-plural#content-0). I've contributed in other fields too ... as example, the fact classes have not enumerable methods and accessors by default [is also my proposal](https://esdiscuss.org/topic/classes-and-enumerability#content-0). Ultimately here it's _crickets_ ... every topic diverted into something else not intended, everything over-complicated for no reason, and stuff stuck for ages because the change _isn't too big, hence not too compelling_. It's a bad way forward for JS and I hope things will change in the near future ... gatekeeping never worked too well in history neither. I respectfully wish you a lovely rest of the day and week and close this thread because there's nothing else for me to discuss: it's clear what I've proposed, and it's also clear nobody gives an eff about it in this space, many do in other venues. Regards đź‘‹ [Previous page](https://es.discourse.group/t/is-it-too-late-to-fix-object-entries/1407.md?page=1)