2013/5/20 Andrea Giammarchi <[email protected]> > 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? >
Yes, there's a `getPrototypeOf` trap. I'm not claiming that putting `getPrototypeOf` on Object and in the reflection module, while putting `setPrototypeOf` only in the reflection module is necessarily better. It is a bit inconsistent, but `Object.getPrototypeOf` existed before proxies and the reflection module, while `setPrototypeOf` is new. The ES6 reflection module is the obvious best place to put functionality like this. Arguably, if we'd had a module like this earlier, it would have housed most of the static methods currently defined on Object. It is unfortunate that the reflection module must duplicate a lot of the Object statics from ES5. Going forward however, there is nothing forcing us from continuing this pollution of Object (except of course that the reflection module depends on modules, hence ES6 syntax, while adding a new static to Object does not. That would be a pragmatic reason to still add Object.setPrototypeOf.) > 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`? > To date, proxies didn't specify how to interact with `__proto__` since `__proto__` fell outside the spec proper. For direct proxies, one does not necessarily need a trap. Indeed, I just tested on Firefox 21 and if you extract the __proto__ setter and apply it to a proxy, it will set the prototype of its target object without trapping. 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. > Indeed, it's inconsistent with ES5. But considering the broader ES6 and beyond time frame, now might be a good time to stop and consider whether we want to keep "polluting" the Object built-in with these methods. Admittedly it has worked fine in practice, and there is precedent even in ES6 to continue doing it (e.g. Object.getOwnPropertyKeys). Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
