> 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 .
On Tue, Nov 27, 2018 at 3:59 AM Andrea Giammarchi <[hidden email]> wrote:
FWIW I'd change the name to inherited:
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.