Discuss
  • New: proposal-known-keys

New: proposal-known-keys

# Ranando King (6 years ago)

This proposal adds 7 new static methods to Object that add support for dealing with all of the enumerable properties of objects with prototypes.

# Ranando King (6 years ago)

Forgot to addd the link....

rdking/proposal

# T.J. Crowder (6 years ago)

On Tue, Nov 27, 2018 at 5:14 AM Ranando King <kingmph at gmail.com> wrote:

Do you have any evidence to back up the assertions in the Motivation section? I haven't seen an issue with people making odd design decisions "just" to make properties own properties.

-- T.J. Crowder

# Andrea Giammarchi (6 years ago)

FWIW I'd change the name to inherited:

  • assignInherited
  • inheritedKeys
  • ...

and I'd probably skip own, at least it's clear the method does something else.

However, it might end up like Object.assign(Object.assignInherited(target, source), source) so that maybe it's better if inherited copies also own properties.

# Ranando King (6 years ago)

However, it might end up like

Object.assign(Object.assignInherited(target, source), source) so that maybe it's better if inherited copies also own properties.

Andrea, that's why I'm using "known". Basically, if (prop in obj) and prop is enumerable, then it will appear in Object.knownKeys(obj). These modified versions take into account all "known" enumerable keys. I could also see a set of "inherited" functions, but I can't see where they'd have the same utility as "own" and "known".

I haven't seen an issue with people making odd design decisions "just"

to make properties own properties.

T.J., The limitations of the existing functions are a current and (even in my book) valid argument in favor of the public-fields proposal. But the public-fields proposal introduces a lesser-of-2-evils type problem into the language:

  • choose [[Set]] semantics and risk losing some future potential for language expansion
  • choose [[Define]] semantics and break inheritance involving accessor properties
  • choose both and increase the complexity of the engine, leaving the decision to the developer as per current ES
  • choose neither and deal with either the objects-on-prototype foot-gun or developers being too sloppy with super

Currently, public-fields is attempting to push through the 2nd option here, despite the damage it will cause. That's an odd design decision, especially considering the 3rd option is superior to the first 2, and the 4th option is even more viable still if the foot-gun is surgically fixed. As you already know, I've got a proposal for that .