Object.prototype.get & bye bye Object.defineProperty

Herby Vojčík herby at mailbox.sk
Sat Dec 1 05:14:46 PST 2012

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 

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


More information about the es-discuss mailing list