does `Proxy` trap `Object.getPrototypeOf` somehow ? If yes, why do you think having two namespaces for the prototype operation is better? If not, why do you think that is not needed in case of getting the prototype?
In any case, how `Object.setPrototypeOf` differs anyhow compared to how the `__proto__` was suposed to be retrieved or set before Allen proposal (if not that is cleaner, less obtrusive, and more elegant plus it works consistently with `Object.create(null)` objects too)? Wasn't `__proto__` demanding some trap too on a generic `Proxy`? I personally think that having `getPrototypeOf` in the `Object` and `setPrototypeOf` in the `Reflect` is inconsistent and developers should be aware of what they are doing regardless the chosen namespace. Thanks for any extra clarification for my questions. Regards On Mon, May 20, 2013 at 8:17 AM, Tom Van Cutsem <[email protected]> wrote: > 2013/5/9 Brendan Eich <[email protected]> > > Andreas Rossberg wrote: >> >> (And let's bury setPrototypeOf quickly.) >>> >> >> Bury how? IIUC this goes in main spec alongside ES5's >> Object.getPrototypeOf, requires a proxy trap, etc. > > > Here's one potential alternative: add Reflect.setPrototypeOf but not > Object.setPrototypeOf. > > Rationale: > - Under Allen's proposal upstream of this thread, proxies will require a > setPrototypeOf trap, regardless of whether we expose Object.setPrototypeOf > (proxies will need to intercept protosetter.call) > - every trap in the Proxy API has a corresponding method with matching > signature in the reflection module to make it easy for proxies to forward > intercepted ops. > - it follows that we'll have Reflect.setPrototypeOf in the reflection > module > > The question then becomes whether we additionally want to expose an > Object.setPrototypeOf alias for this method. > > Putting the setPrototypeOf method only in the reflection API but not on > Object could be a way of telling developers that setting the prototype of > an object is a reflective operation, to be used with some care, not a > general utility function to be used routinely. > > Cheers, > Tom > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
