You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 26, 2022. It is now read-only.
@ljharb just linked to tc39/proposal-object-from-entries#13, which suggested having a prototype parameter for Object.fromEntries similar to the first parameter of Object.create. Given the issues with objects-as-dictionaries inheriting from Object.prototype, we could nicely deal with them by supporting that in toObject:
This of course would mean dropping the "key selector" and "value selector" parameters, but I don't think those were a good fit anyway. Most mapping over dictionaries will be over their entries using the established key-value tuple convention, and even when reducing an iterator of something else to an object, you could just add an additional map step that produces the tuples. This might even be faster since only one function needs to be called per entry - assuming no inlining occurs and that escape analysis gets the array literal allocated on the stack.
The text was updated successfully, but these errors were encountered:
Dropped toObject from the proposal, as Object.fromEntries will do the job for now. We can circle back to toObject later in another proposal once the Iterator Helpers proposal is finalized.
@ljharb just linked to tc39/proposal-object-from-entries#13, which suggested having a prototype parameter for
Object.fromEntries
similar to the first parameter ofObject.create
. Given the issues with objects-as-dictionaries inheriting fromObject.prototype
, we could nicely deal with them by supporting that intoObject
:This of course would mean dropping the "key selector" and "value selector" parameters, but I don't think those were a good fit anyway. Most mapping over dictionaries will be over their entries using the established key-value tuple convention, and even when reducing an iterator of something else to an object, you could just add an additional
map
step that produces the tuples. This might even be faster since only one function needs to be called per entry - assuming no inlining occurs and that escape analysis gets the array literal allocated on the stack.The text was updated successfully, but these errors were encountered: