About private names

Irakli Gozalishvili rfobic at gmail.com
Mon Mar 21 14:41:11 PDT 2011

On Mon, Mar 21, 2011 at 19:29, Andrew Dupont <mozilla at andrewdupont.net>wrote:

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

Andrew I think you misunderstand this feature, as prototypejs is a perfect
fit for it!!
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:

-- lib.js --

private clone;
private extend;

Object.extend = function() {}
Object.prototype.clone = function() { .... }
Array.prototype.clone = function() { ... }

exports.extend = extend;
exports.clone = clone;

-- consumer.js --

private clone = require("lib.js").clone;
private superExtend = require("lib.js").extend

{ a: 'b' }.clone(); // { a: 'b' };

Object.extend = function () {
    // do something else

// note that extend does not overrides `extend` defined by lib.js

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.

> 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110321/574b6cc5/attachment-0001.html>

More information about the es-discuss mailing list