B.3.1 The __proto__ pseudo property
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...
More information about the es-discuss