On Oct 16, 2012, at 9:11 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >>> The module vs. let scope is also interesting. Allen said the literature >>> favored the latter but that wasn't clear from my nowhere-near-comprehensive >>> reading. >> >> Presumably that is a large part of our motivation for providing lexically >> scoped let/const/function/class rather than the semi-global function >> scoping. > > True for bindings but not clear for private/friend visibility qualifiers. > Other languages do not all block-scope those, more the reverse: class or > package/library scope.
Yes, but what are we talking about here. ES6 symbols are a kind of value, not a visibility qualifier. At-names, are a name binding for those values. Neither of these are visibility qualifiers, that is just a use case for them (although probably the primary use case). We can't just look at what other languages do for visibility qualifiers, we also have to work in the context at how name binding is handled in ES. The symbol path is a different approach to controlling member access than used in C++/Java etc. Symbols are much closer in-concept to Ruby instance variables, except that in Ruby the bindings are scoped to a class (actually a class hierarchy, in that sense they have "protected" visibility). > >> I believe the main arguments against implicit declarations are: >> 1) they catch misspelling inconsistencies (but not consistent >> misspellings) > > Good parenthetical point (and one near and dear to my heart, probably yours > too ;-). Indeed! > >> 2) they prevent unintended share via coincidental common name selection > > > You mean the allow unintended sharing? yes > > Yes, private prefixes and declarations are more powerful. Main questions I > see Kevin raising are usability and overkill. Say we reject "overkill" for > good reason. We may still have usability woes. 'private' is seven long > letters, eight with the space after. "priv"?? "sym"?? Plus as an OO developer, "protected" is what I really want... We also have the issue that we have orthogonal differences (reflection) between "public" and private symbols and as long as we have them, there needs be a way to designate which is intended. The root question might be whether the symbol approach truly provides a usable solution for the encapsulation use case. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
