Maybe some little kind of protection would be helpful.
One of minimal solution I see is to have a well-known object that holds
all of the descriptor defaults (Reflect.defaultPropertyDescriptor), and:
- when returning descriptor from API, make it `__proto__:R.dPP`
- when creating descriptor, evangelize users to create something like
`function pd(o) { o.__proto__=R.pdd; return o; }`
and use it for creating either plain descriptor inline, or roots for
reuse in their own Object.create scenarios; or - you can even have it in
Reflect as function on its own (`safePropertyDescriptor`), just people
won't use it when it have long name so at least they should be
evangelized to do `let dp=Reflect.safePropertyDescriptor;` and use
`pd(...)`.
Brendan Eich wrote:
Andrea Giammarchi wrote:
I really don't understand what is exactly the advantage of considering
inherited properties for descriptors.
It's easy to overreact here. Don't mess with Object.prototype still
applies, or you will have other WTF moments.
ES5 shipped this and browsers shipped implementations. David and others
use it. I don't think we can change it.
The ES5 meta-object APIs are pretty much power-tools, with obvious
verbosity and usability taxes. Better (more concise and usable) veneer
on top has been done and should bubble up on github. This is not to
excuse anything, but any process (standardized de-jure or not) that
releases platform iterations to millions of developers will face this
pain. Node.js is facing it now.
So I say doc this, evangelize it, and build better APIs on top of ES5.
TC39 people are tracking.
/be
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
