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 <[email protected]> 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 :-) Regards
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
