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.
Cheers,
Andrew
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
