B.3.1 The __proto__ pseudo property

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon May 20 10:55:47 PDT 2013

I believe having a counterpart in the Object, following a natural
expectation where for a get you've got a set, is just fine but surely
Reflect should have its own "reflection power" a part.

I see Reflect more like an introspection tool able to understand things and
not necessarily mutate them ( yes, similar to what is ReflectionClass or
ReflectionMethod in PHP, that worked there, still you cannot change an
object class ).

Reflect is a good place to put a `fn.caller` equivalent and not to set one,
so I don't see `setPrototypeOf` a good fit for that namespace.

If it is, talking about graceful migration, `setPrototypeOf` could be on
both globals, with the `Object` version warning in console about being
deprecated as soon as next specs are aout where there won't be anything
anymore in the `Object` but this sounds quite unrealistic so I'd rather
using what worked 'till now, the global `Object`

Just my 2 cents

On Mon, May 20, 2013 at 9:54 AM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:

> 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.

if you want to know my opinion, this is scary and undesired :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130520/71651b95/attachment.html>

More information about the es-discuss mailing list