Hi, After seeing this thread I really though it's important to share my thought on this as well. So when I first sew this proposal my reaction was similar to Andrew's. It took me a while to realize that issues with shadowing were not as big as they felt at first. In fact only case where shadowing may affect you unintentionally is when it's hang out in the global scope, but again modules and other changes to ES.next are making it non issue. Also it's worth noticing that today all the frameworks define themself in their own lexical scopes (self executable functions).
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 would encourage to writing examples of where name shadowing may cause confusions, and iterate on them :) Also I think there is one thing (that may not be an issue either) that may be improved: var foo = someModule.bar(); It's hard to know what `foo` is on the next line, as it may be a private name that will change behavior of lexical scope or it maybe just a value returned by function, even worth doe the bug in `bar` it may end up being a private name instead of variable that will completely break my program. Would be nice to have a better control of that. For example private foo = someModule.bar(); would be explicit, also will make it way more simple to inspect source to see what names are shadowed. Regards -- Irakli Gozalishvili Web: http://www.jeditoolkit.com/ Address: 29 Rue Saint-Georges, 75009 Paris, France <http://goo.gl/maps/3CHu> On Mon, Mar 21, 2011 at 07:30, Andrew Dupont <mozi...@andrewdupont.net>wrote: > > 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
