July 26, 2012 TC39 Meeting Notes

Tom Van Cutsem tomvc.be at gmail.com
Mon Jul 30 04:49:31 PDT 2012


2012/7/28 Brendan Eich <brendan at mozilla.org>

> Tom Van Cutsem wrote:
>
>>
>> As I recall it, the discussion was inconclusive. As stated, I would favor
>> a new operation (like Object.getNames) that makes explicit the fact that it
>> returns name objects, rather than overloading existing methods.
>>
>
> Yes, I thought we agreed (see "when in doubt, use brute force" ... "if it
> didn't work, use more brute force") to have more traps: for each trap
> taking a string identifier, add an optional trap taking a Name identifier.
>

As I recall, we agreed that we needed at least extra traps for all traps
that took a string identifier as an argument, but we did not talk through
whether we also needed extra traps for all traps that return (an array of)
string identifiers (that would be "keys", "getOwnPropertyNames" and
"enumerate").

My sense is we'll need alternatives for keys and gOPN (listing only unique
names?). There should be no need for a Name alternative to "enumerate"
since the for-in loop only ever enumerates string-valued property names.


> However, we did not agree on avoiding a flag to overload Name to create
> private vs. unique name objects, or an options argument to
> Object.getOwnPropertyNames. But I sense some of us believe that "add a flag
> option" is undesirable based on experience, both JS-specific and
> language-neutral:
>

We could go for Name.createUnique() and Name.createPrivate(). But with
modules, maybe it's no longer an issue to just introduce 2 separate Name
constructors.


> [...]
>
> So do we need UniqueName and PrivateName constructors? If yes, this would
> not imply that we need to split traps further, of course, since both
> UniqueName and PrivateName would create Name objects. Or we could use an
> optional flag parameter to one Name constructor and defy the anti-pattern
> wisdom.


Just to be clear: the unique vs. private split for Names is orthogonal to
the name vs. string split for proxy traps. So indeed: splitting Names
shoudn't cause further splits for proxy traps.


>
>  Regarding the extra traps needed for private names: I scanned the list of
>> traps and I think we need to duplicate each trap that takes a property name
>> (a String) as argument, so we'll end up with:
>>
>> get -> getName
>> set -> setName
>> has -> hasName
>> hasOwn -> hasOwnName
>> defineProperty -> defineName
>> deleteProperty -> deleteName
>> getOwnPropertyDescriptor -> getOwnNameDescriptor?
>>
>> (the last three names are a bit inconsistent since I don't want to be
>> known as the guy that inflicted getOwnPropertyDescriptorName upon the world
>> ;-)
>>
>
> Alternatives, call your list 0:
>
> 1. Verbose but always end in "Name", requiring "By" in some cases:
> getName, setName, hasName, hasOwnName, definePropertyByName,
> deletePropertyByName, getOwnPropertyDescriptorByName**.
>
> 2. Prefix uniformly FTW: nameGet, nameSet, nameHas, nameHasOwn,
> nameDefineProperty, nameDeleteProperty, nameGetOwnPropertyDescriptor.
>
> My preference: 2 > 1 > 0. Other opinions?


Ok, I'm swayed by your argument in favor of a consistent prefix or suffix.
I'd prefer 1 (suffix) as the selectors read more naturally as requests
rather than as commands.

We might still consider shortening getOwnPropertyDescriptorByName (30
chars!) to getOwnPropertyByName. After all, there's no corresponding
Object.* method to match. A new matching method will live in the reflect
module though.

Which reminds me: we can now stop adding more methods such as the
hypothetical Object.getNames to Object and consider Reflect.getNames
instead (probably Reflect.getUniqueNames).

(Note that we already have Object.getOwnPropertyNames which has nothing to
do with "Names". We should think carefully about how to avoid confusion.)

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120730/919ac3e4/attachment.html>


More information about the es-discuss mailing list