<div dir="ltr">2014-07-26 5:43 GMT+02:00 Axel Rauschmayer <span dir="ltr"><<a href="mailto:axel@rauschma.de" target="_blank">axel@rauschma.de</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>ECMAScript 6 mostly eliminates the need to call methods generically (no need to use the array-like `arguments`, `Array.from()`, spread operator, etc.).</div><div><br></div><div>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()`?</div>
</div></blockquote><div><br></div><div>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 Reflect.hasOwn (in keeping with the symmetry between these Reflect.* utilities and the Proxy traps).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Tom</div></div></div></div>