>
> 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 that this doesn’t
js
// assign it once per module/scope
var hOP = Object.hasOwnProperty;
// whenever is needed
hOP.call({key: 'value'}, 'key'); // true
hOP.call({value: 'key'}, 'key'); // false
```
Beside the top level copy&paste operation to define `hOP`, writing
`hOP.call(o,k)` is less
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 clar
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
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
> unfortunate name),
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 s
place. 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
replac
2014-07-27 18:14 GMT+02:00 Mark S. Miller :
> 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.
On Sunday, July 27, 2014, Tab Atkins Jr. wrote:
> On Sat, Jul 26, 2014 at 11:36 AM, Kevin Smith > 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. Ob
On Sun, Jul 27, 2014 at 6:14 PM, Mark S. Miller 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
> not seem practi
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. It
On Sun, Jul 27, 2014 at 1:57 PM, David Bruant 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 too late.
> My poi
Le 27/07/2014 13:35, Peter van der Zee a écrit :
On Sat, Jul 26, 2014 at 5:14 PM, Mark S. Miller 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
On Sat, Jul 26, 2014 at 5:14 PM, Mark S. Miller 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
_
On Sat, Jul 26, 2014 at 11:36 AM, Kevin Smith 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 as object li
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
>
> 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
https://ma
>
>
> 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'
On Jul 26, 2014, at 20:36 , Kevin Smith 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 as object litera
>
>
> * 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
> 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
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 g
t; > 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 y
>
>
> 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.
>
>
Soun
t; 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()`?
>
Reflect.hasOwn was actually included in the Reflect API initially, as the
dual to the Proxy "hasOwn" trap. When we decided to
nd 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,
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(&
On Sat, Jul 26, 2014 at 5:43 AM, Axel Rauschmayer 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()`?
That woul
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
29 matches
Mail list logo
