Is it too late to fix `Object.entries` ???

💡 Ideas
21

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]]))

2 Likes
22

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.

23

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.

1 Like
24

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.

25

@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.

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?

26

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.

27

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.

28

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.

29

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.

30

I am coming from times where entries were cool for a Map.from proposal too 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.

Object.fromEntries is not broken for modern JS, Object.entries is ... because it doesn't understand modern JS, like symbols.

Everyone on twitter istantly understood what is broken by reading my very first example ... 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.

I've contributed in other fields too ... as example, the fact classes have not enumerable methods and accessors by default is also my proposal.

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 :wave:

1 Like