B.3.1 The __proto__ pseudo property

Tom Van Cutsem tomvc.be at gmail.com
Mon May 20 09:54:42 PDT 2013


2013/5/20 Andrea Giammarchi <andrea.giammarchi at gmail.com>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130520/413c000c/attachment.html>


More information about the es-discuss mailing list