Andrea Giammarchi andrea.giammarchi at
Wed Sep 7 08:52:37 UTC 2016

Just my 2 cents.

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

// meet callerOf
function callerOf(c) {return}

// 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:

// assign it once per module/scope
var hOP = Object.hasOwnProperty;

// whenever is needed{key: 'value'}, 'key'); // true{value: 'key'}, 'key'); // false

Beside the top level copy&paste operation to define `hOP`, writing
`,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


On Wed, Sep 7, 2016 at 9:34 AM, Maël Nison <nison.mael at> 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> 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> 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> 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.
>>>> 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
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list