About private names

Andrew Dupont mozilla at andrewdupont.net
Mon Mar 21 11:29:29 PDT 2011

On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:
> Hi Andrew, thanks for the good thinking on this thread. I'm not cherry-picking here, but I wanted to reply to the specific sentence ending "entire lexical scope".
> The Harmony top-level scope (no global object!) will be big and it may even grow by (non-colliding) extension, sure. Hence Dave's thought of not allowing private there.
> Anyway, I wanted to check this (what I took to be your own experience-based) weighting of search space sizes.

This is a good point — I'm imagining lexical scopes that, at their largest, can span the entirety of a very large library like Prototype or jQuery.

In recent years, Prototype has moved toward defining each of its sections in a separate anonymous function, declaring named functions inside of it, then selectively "exporting" some of them to the global scope. This is an increasingly common trend. In the future, I can see us moving toward a system where the whole library follows that pattern — one giant anonymous function surrounding the whole thing.

Not allowing private in the top-level scope would help a bit (at the cost of hindering the "Conflict-Free Object Extension Using Private Names" use case), but any lexical scope can grow to a staggering size.

On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:
> Is a lexical scope bigger and harder to search than two or more class files in Java? Ignoring IDEs, this seems to suggest lexical scopes tend to be "big". Is this based on your experience with JS blocks (not function bodies or global scopes) today?

Until now, yes, I have been imagining a function body as an example of a lexical scope. Why are you excluding it?

On Mar 21, 2011, at 3:11 AM, Irakli Gozalishvili wrote:
> Also I think this proposal won't be really useful without syntax sugar. To elaborate more, I think this is a perfect feature for libraries that extend built-ins like prototype, or mootools or their extensions may be defined as private names that consumers may decide to use by importing names, or rename or just ignore entirely.

I'm co-maintainer of Prototype and I'm saying I can't imagine we'd use this feature under the proposed syntax. And — again — I'm not opposed to syntactic sugar in general, only to this specific syntax.

On Mar 21, 2011, at 11:50 AM, David Herman wrote:
> This is true. But because *you* control the local view of the private name, and that local binding is not exposed to anyone else, you can always rename your local name out of the way.

People keep saying this. It may be true, but it undermines one of the stated goals of the proposal. The whole point of Prototype's built-in extension is to introduce more intuitive ways of working with built-ins and to fill perceived gaps. Naming is a large part of that. `{}.myClone` is, in my view, vastly inferior to `{}.clone` because of its unintuitive naming. As a hypothetical consumer, I'm hardly impressed with a library that promises conflict-free usage of an instance method on objects... as long as I name the method uniquely and am careful about scoping.

On Mar 21, 2011, at 11:50 AM, David Herman wrote:
> How often would people really bind private names in large scopes? I honestly -- in good faith -- don't know.

Well, again, the "Conflict-Free Object Extension Using Private Names" use case explicitly encourages using private names in large scopes. But I don't know either; I'm just trying to give my perspective as a library author. _Everything_ about this syntax screams "footgun," both for me and for users of Prototype. Aside from writing large amounts of code with the proposed syntax, I'm not sure what I can do to illustrate this, but I'm open to ideas.


More information about the es-discuss mailing list