<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/5/20 Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">does `Proxy` trap `Object.getPrototypeOf` somehow ?<div>If yes, why do you think having two namespaces for the prototype operation is better?</div><div>If not, why do you think that is not needed in case of getting the prototype?</div>
</div></blockquote><div><br></div><div style>Yes, there's a `getPrototypeOf` trap.</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div>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)?<br>
</div>
<div><br></div><div>Wasn't `__proto__` demanding some trap too on a generic `Proxy`?</div></div></blockquote><div><br></div><div style>To date, proxies didn't specify how to interact with `__proto__` since `__proto__` fell outside the spec proper.</div>
<div style><br></div><div style>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br>
</div></div></blockquote><div><br></div><div style>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).</div>
<div style><br></div><div style>Cheers,</div><div style>Tom</div></div></div></div>