<br><br><div class="gmail_quote">On Mon, Mar 21, 2011 at 19:29, Andrew Dupont <span dir="ltr"><<a href="mailto:mozilla@andrewdupont.net">mozilla@andrewdupont.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><br>
On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:<br>
> 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".<br>
><br>
</div><div class="im">> 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.<br>
><br>
> Anyway, I wanted to check this (what I took to be your own experience-based) weighting of search space sizes.<br>
<br>
</div>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.<br>
<br>
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.<br>


<br>
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.<br>


<div class="im"><br>
<br>
On Mar 21, 2011, at 11:14 AM, Brendan Eich wrote:<br>
> 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?<br>


<br>
<br>
</div>Until now, yes, I have been imagining a function body as an example of a lexical scope. Why are you excluding it?<br>
<div class="im"><br>
<br>
On Mar 21, 2011, at 3:11 AM, Irakli Gozalishvili wrote:<br>
> 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.<br>


<br>
<br>
</div>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.<br>

</blockquote><div><br>Andrew I think you misunderstand this feature, as prototypejs is a perfect fit for it!!<br>What I mean is that prototype could define all the extensions names it introduces in the top of the lexical scope and export those names along with framework. That will allow consumers to choose which extensions they intend to import and which not. Some even may decide to change names (bike-shedding is very popular in JS :) Here is an example:<br>

<br><br>-- lib.js --<br><br>private clone;<br>private extend;<br><br>Object.extend = function() {}<br>Object.prototype.clone = function() { .... }<br>Array.prototype.clone = function() { ... }<br><br>exports.extend = extend;<br>

exports.clone = clone;<br><br>-- consumer.js --<br><br>private clone = require("lib.js").clone;<br>private superExtend = require("lib.js").extend<br><br>{ a: 'b' }.clone(); // { a: 'b' };<br>

<br>Object.extend = function () {<br>    Object.superExtend.apply(...);<br>    // do something else<br>}<br><br>// note that extend does not overrides `extend` defined by lib.js<br><br>My point is that library can uses internal names as they used it before, but if they will define their extensions as names they make them opt-in for consumers of lib.<br>

   <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
<br>
On Mar 21, 2011, at 11:50 AM, David Herman wrote:<br>
> 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.<br>
<br>
<br>
</div>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.<br>


<div class="im"><br>
<br>
On Mar 21, 2011, at 11:50 AM, David Herman wrote:<br>
> How often would people really bind private names in large scopes? I honestly -- in good faith -- don't know.<br>
<br>
</div>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.<br>


<br>
Cheers,<br>
<font color="#888888">Andrew<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
</div></div></blockquote></div><br>