July 26, 2012 TC39 Meeting Notes

Brendan Eich brendan at mozilla.org
Sat Jul 28 14:52:57 PDT 2012


Tom Van Cutsem wrote:
>
>     > BE: are they actually distinguishable?
>     >
>     > MM: have to be if name.public === name or name.public !== name
>     distinction
>     >
>     > DH: (named) boolean flag to Name constructor
>     If we have private and unique names, we might as well have 2
>     constructors : PrivateName and UniqueName. I find that more readable
>     than "new Name(true)".
>     > DH: do we have some way of reflecting unique names?
>     >
>     > TVC: Object.getNames() ?
>     >
>     > DH: ugh...
>     >
>     > AWB: maybe a flag to Object.getOwnPropertyNames({ unique: true })
>     >
>     > BE (editing notes): flags to methods are an API design anti-pattern
>     What's the conclusion of this part?
>
> 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.

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:

A. ECMA-262 warns implementations not to extend built-ins with optional 
implementation-specific parameters, for good reason. OTOH, optional 
parameters can bite later on their own, even if added by a later edition 
of the standard. See http://www.wirfs-brock.com/allen/posts/166.

B. See 
http://stackoverflow.com/questions/6107221/at-what-point-does-passing-a-flag-into-a-method-become-a-code-smell, 
http://stackoverflow.com/questions/7150987/python-better-to-have-multiple-methods-or-lots-of-optional-parameters, 
and others. Opinions vary but there's a general consensus that a flag 
should be avoided if possible.

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.

> 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?

/be



More information about the es-discuss mailing list