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 = ...;
shape.draw();
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.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
