About private names

Andrew Dupont mozilla at andrewdupont.net
Sat Mar 19 22:54:43 PDT 2011

On Mar 19, 2011, at 7:02 PM, Sam Tobin-Hochstadt wrote:

> You're correct -- this won't do what you probably intended.  But the
> great thing about private names is that this is a problem you can
> *locally* fix.  For example:
> private myClone = installCloneLibrary();
> var twin = [{a:0}, {b:1}].myClone();
> var thing = MyObj.clone();

Yeah, but at that point one might as well just name the function myClone (replacing "my" with some framework-specific prefix) and eschew private names altogether. In this example, being able to name the method "clone" without fear of naming collisions is the whole point.

> or
> var cloneProp = installCloneLibrary();
> var twin = [{a:0}, {b:1}][cloneProp]();
> var thing = MyObj.clone();

This is more palatable, but I wager it's far harder for end-users to grok.

Anyway, now that I've confirmed my suspicions, I'm hesitant about the private names proposal as described. The fact that declaring a certain name as private affects _all_ property name lookups in that scope (all lookups that use the dot operator or object literal syntax, at least) — well, I'm not sure I like the implications. It would mean a new  and _surprising_ distinction between dot notation and bracket notation.

As a maintainer of a framework that does quite a bit of built-in extension, I can't imagine us using private names for this purpose. If we wanted to define {}.clone in this manner, we'd be exchanging one potential collision (one property defined in one place) for another (every property defined in the same lexical scope). If the private names had their own operator (e.g., twin#clone vs. twin.clone), it'd at least be worth considering.

I'm sure private names would be useful for other reasons, but IMO it wouldn't solve the problem of safely extending built-ins.


More information about the es-discuss mailing list