Reflect.* naming: defineProperty, deleteProperty vs. get, has, set?
deleteProperty was in fact originally called delete. We changed it to
avoid a conflict with the keyword, which occurs when importing the function
(recall that the Reflect.* methods are actually functions exported from a
module). While ES5 made it possible to use keywords as properties, you
obviously still can't use keywords as ordinary function names.
defineProperty is by symmetry with the existing Object.defineProperty
built-in. I believe the symmetry is more important than a shorter name.
Can we change get, set, and has then?
I imagine the symmetry argument applies to hasOwn as well.
hasOwn has been deprecated recently.
As for get, has and set, you mean renaming them to getProperty, setProperty
and hasProperty? I don't see much value in doing so. There are no primitive
operations that require the symmetry, and in practice I've found it
pleasant that the most common operations to intercept (property get and
set) have short names. Also, get and set mirror the corresponding
contextual keywords for accessor properties, which makes sense.
hasOwnhas been deprecated recently.
Why no hasOwn?
On Fri, Jan 31, 2014 at 7:05 AM, Nathan Wall <nathan.wall at live.com> wrote:
Why no
hasOwn?
esdiscuss.org/topic/removing-proxy-hasown-trap-was-invoke-and-implicit-method-calls
(Incidentally, in that thread Allen wrote "...I can't recall specifically why it is still there. I'm pretty sure we've discussed this before." And we had; that discussion is here: esdiscuss.org/topic/do-we-really-need-the-hasownproperty-internal-method-and-hasown-trap)
Is it not possible to do something like: export { deleteProperty as delete } ?
It seems like it would be nicer to change the former to
defineanddelete, respectively?