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