Reflect.hasOwn

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Sep 29 00:12:01 UTC 2016


Just my 2 cents.

The tiniest JS utility I know [1] solves verbosity and freeze the method so
it's also safe.

```js
// meet callerOf
function callerOf(c) {return c.call.bind(c)}

// how to use it
const hasOwn = callerOf({}.hasOwnProperty);

hasOwn({key: 'value'}, 'key'); // true
hasOwn({value: 'key'}, 'key'); // false
```

However, since functions also inherit from `Object.prototype`, I usually
write this shortcut to semantically reach the
`Object.prototype.hasOwnProperty` method, avoiding the need of the
`callerOf` utility:

```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 verbose than `Reflect.hasOwn(o,k)` and strawberry
on top, there's nothing else to explain for something that has been
misunderstood for a very long time ( `hasOwnProperty` through
`Object.prototype` vs `in` )

Best Regards


[1] https://github.com/WebReflection/caller-of#caller-of



On Wed, Sep 7, 2016 at 9:34 AM, Maël Nison <nison.mael at gmail.com> wrote:

> 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 clarity of new codes, and could prevent
> silly mistakes, the kind we all hate to debug (I've been unable to find a
> reliable tool that could search for exact matches in a large number of
> source codes, but I feel like forgetting the .call probably happens every
> once in a while).
>
> Le mer. 7 sept. 2016 à 06:08, Isiah Meadows <isiahmeadows at gmail.com> a
> écrit :
>
>> 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
>> file I use it. Honestly, though, I feel it was a design flaw from the start
>> to be on the prototype, but we can't just time travel and fix it.
>>
>> On Tue, Sep 6, 2016, 16:42 Maël Nison <nison.mael at gmail.com> wrote:
>>
>>> 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 <d at domenic.me> a écrit :
>>>
>>>> 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 support of an
>>>> objects-as-maps programming style which has caused many problems in the
>>>> past and should not be encouraged. See e.g.
>>>> http://www.2ality.com/2012/11/proto-breaks-webapps.html.
>>>>
>>>> If you are using objects-as-maps safely, you’d use Object.create(null),
>>>> in which case the `in` operator works fine and there's no need for
>>>> hasOwnProperty incantations.
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160929/295fb51d/attachment.html>


More information about the es-discuss mailing list