Re: Reflect.hasOwn

> > On Sep 6, 2016, at 4:10 PM, Domenic Denicola wrote: > > Reflect is a namespace that contains the proxy traps (it’s a bit of an > unfortunate name), so we shouldn’t be adding things to it that are not part > of the meta-object protocol. I generally disagree with the idea

Re: Reflect.hasOwn

= Object.hasOwnProperty; // whenever is needed hOP.call({key: 'value'}, 'key'); // true hOP.call({value: 'key'}, 'key'); // false ``` Beside the top level copy operation to define `hOP`, writing `hOP.call(o,k)` is less verbose than `Reflect.hasOwn(o,k)` and strawberry on top, there's nothing else to explain

Re: Reflect.hasOwn

Removing hasOwnProperty from Object.prototype would break a lot of code, so it's not even an option, but we could at least add Object.hasOwn, since Reflect apparently isn't the right place for this (it's a shame, it would mirror nicely with Reflect.ownKeys). Doing this would improve a bit the

Re: Reflect.hasOwn

I'll admit I use them partially out of laziness and partially because engines already optimize for this much better than with actual maps (only string keys). I frequently alias `const hasOwn = Object.prototype.hasOwnProperty`, so this wouldn't do much for me other than saving a declaration in each

Re: Reflect.hasOwn

JSON.parse() and object literals are big sources of objects-as-maps. In both of these cases, using the `in` operator won't give the right answer. Le mar. 6 sept. 2016 à 22:11, Domenic Denicola a écrit : > Reflect is a namespace that contains the proxy traps (it’s a bit of an >

RE: Reflect.hasOwn

Reflect is a namespace that contains the proxy traps (it’s a bit of an unfortunate name), so we shouldn’t be adding things to it that are not part of the meta-object protocol. A new namespace, or using Object, might be OK. I think that it will still be controversial, since this proposal is in

Reflect.hasOwn

. As someone said in the previous thread, hasOwnProperty should have never been added to the Object prototype. According to the discussion, Reflect.hasOwn has been thrown away in order to keep the Reflect API simple, arguing that such a method could easily be replaced

Re: Reflect.hasOwn() ?

2014-07-27 18:14 GMT+02:00 Mark S. Miller erig...@google.com: Although there is some interesting work in trying to obtain security relevant guarantees from a script that isn't first, where a malicious script may instead have been first (link please if anyone has it), this work did not seem

Re: Reflect.hasOwn() ?

On Sat, Jul 26, 2014 at 5:14 PM, Mark S. Miller erig...@google.com wrote: Hi Peter, what is the security issue you are concerned about? Unless `Reflect` is completely sealed out of the box, you can never know whether properties on it are the actual built-ins. That's all. - peter

Re: Reflect.hasOwn() ?

Le 27/07/2014 13:35, Peter van der Zee a écrit : On Sat, Jul 26, 2014 at 5:14 PM, Mark S. Miller erig...@google.com wrote: Hi Peter, what is the security issue you are concerned about? Unless `Reflect` is completely sealed out of the box, you can never know whether properties on it are the

Re: Reflect.hasOwn() ?

On Sun, Jul 27, 2014 at 1:57 PM, David Bruant bruan...@gmail.com wrote: You can deeply freeze it yourself before any other script accesses it. That's already assuming you are first. You may not be without your knowledge (ISP injection, virus hijack, garden gnomes, etc). At this point you'll be

Re: Reflect.hasOwn() ?

Although there is some interesting work in trying to obtain security relevant guarantees from a script that isn't first, where a malicious script may instead have been first (link please if anyone has it), this work did not seem practical to me. My POV: A realm starts out pervasively malleable.

Re: Reflect.hasOwn() ?

On Sun, Jul 27, 2014 at 6:14 PM, Mark S. Miller erig...@google.com wrote: Although there is some interesting work in trying to obtain security relevant guarantees from a script that isn't first, where a malicious script may instead have been first (link please if anyone has it), this work did

Re: Reflect.hasOwn() ?

On Sunday, July 27, 2014, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Jul 26, 2014 at 11:36 AM, Kevin Smith zenpars...@gmail.com javascript:; wrote: * As far as I can tell, `hasOwnProperty` is mainly used to implement maps via objects. `Map` will eliminate this use case. To a

Re: Reflect.hasOwn() ?

mind is `{}.hasOwnProperty.call(obj, key)` (which is the only safe way to invoke this method). Would it make sense to provide that as a tool function, e.g. as `Reflect.hasOwn()`? That would make it unsafe again. Not so much from random people polluting the global Object, but certainly unsafe from

Re: Reflect.hasOwn() ?

)` (which is the only safe way to invoke this method). Would it make sense to provide that as a tool function, e.g. as `Reflect.hasOwn()`? Reflect.hasOwn was actually included in the Reflect API initially, as the dual to the Proxy hasOwn trap. When we decided to remove the trap, we also threw out

Re: Reflect.hasOwn() ?

The rationale to remove Reflect.hasOwn was that it could easily be simulated via (Reflect.getOwnPropertyDescriptor(obj,name) !== undefined). While this conses a throw-away property descriptor object, the overhead was deemed insignificant. Sounds good. Still, hanging hasOwnProperty off

Re: Reflect.hasOwn() ?

sense to provide that as a tool function, e.g. as `Reflect.hasOwn()`? That would make it unsafe again. Not so much from random people polluting the global Object, but certainly unsafe from a security perspective. Hi Peter, what is the security issue you are concerned about? - peter

Re: Reflect.hasOwn() ?

: The rationale to remove Reflect.hasOwn was that it could easily be simulated via (Reflect.getOwnPropertyDescriptor(obj,name) !== undefined). While this conses a throw-away property descriptor object, the overhead was deemed insignificant. Sounds good. Still, hanging hasOwnProperty off

Re: Reflect.hasOwn() ?

Overall, I'm leaning towards keeping the built-in Reflect API minimal. There's room for many more utility methods (Reflect.getPropertyDescriptors comes to mind) which can all be expressed as a library. After thinking about it some more, I agree w.r.t. these two examples: * As far as I can

Re: Reflect.hasOwn() ?

* As far as I can tell, `hasOwnProperty` is mainly used to implement maps via objects. `Map` will eliminate this use case. To a certain extent yes, but not completely. Objects-as-maps will still be used quite frequently as object literals passed into functions (as an options object, for

Re: Reflect.hasOwn() ?

On Jul 26, 2014, at 20:36 , Kevin Smith zenpars...@gmail.com wrote: * As far as I can tell, `hasOwnProperty` is mainly used to implement maps via objects. `Map` will eliminate this use case. To a certain extent yes, but not completely. Objects-as-maps will still be used quite frequently

Re: Reflect.hasOwn() ?

Did you mean `Reflect.ownKeys()`? I meant Object.keys. That will eliminate the inconsistency between Object.keys usage and hasOwnProperty usage that crops up sometimes: https://github.com/joyent/node/issues/7587 When dealing with objects-as-maps, it's usually just the key-ness that you're

Re: Reflect.hasOwn() ?

I meant Object.keys. That will eliminate the inconsistency between Object.keys usage and hasOwnProperty usage that crops up sometimes: Nevermind. Brain-stall. Sorry about the noise. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Reflect.hasOwn() ?

On 7/26/14, 5:33 AM, Tom Van Cutsem wrote: The rationale to remove Reflect.hasOwn was that it could easily be simulated via (Reflect.getOwnPropertyDescriptor(obj,name) !== undefined). While this conses a throw-away property descriptor object, the overhead was deemed insignificant. That depends

Reflect.hasOwn() ?

it make sense to provide that as a tool function, e.g. as `Reflect.hasOwn()`? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Reflect.hasOwn() ?

On Sat, Jul 26, 2014 at 5:43 AM, Axel Rauschmayer a...@rauschma.de wrote: The only exception that comes to my mind is `{}.hasOwnProperty.call(obj, key)` (which is the only safe way to invoke this method). Would it make sense to provide that as a tool function, e.g. as `Reflect.hasOwn

Re: Reflect.hasOwn() ?

to provide that as a tool function, e.g. as `Reflect.hasOwn()`? That would make it unsafe again. Not so much from random people polluting the global Object, but certainly unsafe from a security perspective. With “safe”, I only meant w.r.t. overriding (e.g., `obj.hasOwnProperty('foo')` fails