About private names

David Herman dherman at mozilla.com
Mon Mar 21 09:50:36 PDT 2011

Brendan and Irakli both beat me to the punch here -- I would really like to see stronger evidence that "an entire lexical scope" is really so onerous. Everything you say about how Java mitigates the problem is just as applicable to Harmony.

> Java doesn't formalize this, you're right — but if I'm looking at `this.doSomething()` and wondering about its visibility, I can look in the class definition itself (to see if it's private) or in one of its superclasses (to see if it's protected). Java does formalize the locations of class files, so I know exactly where to look to get my answer.

So does Harmony. You can find where everything is defined, so there's no question as to whether something is declared to be private.

> I think that's a far smaller area to have to search than an entire lexical scope.

In Java it is, in fact, *more* than an entire lexical scope. A private field is lexically scoped, but it can also be called on an object, so you also have to look up the type definition.

> Two minor points, though: (a) many coding styles notate private members with underscores, so that it's obvious at a glance what is private and what is not;

...So, JS programmers could do the same thing.

> (b) many Java authors use "heavy" IDEs which can settle the question without sending the author off on a hunt (in Eclipse, it just requires hovering over the identifier, IIRC). JavaScript authors wouldn't necessarily be able to rely on that level of help from their editors.

There's no reason why they couldn't. JS editors are getting better and better (see, for example, the Ace, CodeMirror, and Orion editors), and because this is dependent only on lexical scope, and not for example on type information which JS editors don't have, it's really easy to for an editor to implement.

> And one more major point: Java's visibility rules differ in important ways. It is true that I can't define a public `doSomething` method and a private `doSomething` method in the same class, but that collision is only within the class itself. Yet under the proposed syntax, if I introduce `doSomething` as a private name in any scope, that prevents me from referring to _anything_ with that public name in the same lexical scope.

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. For example, the Cowboy/Shape example I gave previous could safely be rewritten:

    private drawGun;
    Cowboy.prototype = {
        drawGun: function() { ... },
    var shape = ...;

and now there's no conflict. Renaming the local binding from draw to drawGun doesn't change anything about the private name itself, since at runtime it's just a fresh key. The local name is just a local view of the private key.

I'm a bit on the fence here, but Allen raised very good points about refactorability, and Irakli raise good doubts about how much your concern is likely to be a problem in practice. This isn't an obvious design decision, and rather than treat it as a binary between right and wrong, I would urge you to try to think about compelling evidence of practical hazards. AFAICT, the biggest hazard is in forgetting that something is bound as a private name and accidentally referring to a public name as a private one. But how common would this be? How often would people really bind private names in large scopes? I honestly -- in good faith -- don't know.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110321/2195ce4a/attachment.html>

More information about the es-discuss mailing list