On Mar 21, 2011, at 12:50 AM, Allen Wirfs-Brock wrote: > On Mar 20, 2011, at 9:58 PM, Andrew Dupont wrote: > >> The revision would address all my concerns — thanks. I'm all for >> distinguishing the static case from the dynamic case, as long as we can >> maintain the separation between public names and private names, and know >> which is which without indirection. > > Can you explain why you feel this is important. I note that it is not a > characteristic of some of the most common used object oriented, even those > that support explicit member visibility declarations. more concretely, if > I'm examine a line of Java code that reads like: > this.doSomething(); > there is nothing explicit that tell me the visibility of doSomeThing or that > it is referring to a member that perhaps has different visibility than what > is referenced by: > that.doSomething();
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. I think that's a far smaller area to have to search than an entire lexical scope. 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; (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. 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. It'd be like Java telling me I couldn't call `someObject.doSomething()` within a class because I had declared my own personal unrelated `doSomething` method as private. My _main_ objection is the idea of private names that "shadow" public identifiers. The point about indirection is secondary — but also important, IMO, because the proposed syntax would be introducing indirection in a place where there was none previously. I liked David Herman's proposal because it addressed both parts. Cheers, Andrew _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
