Modular At-Names

Allen Wirfs-Brock allen at
Tue Oct 16 11:02:10 PDT 2012

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 ;-).

>>    2) they prevent unintended share via coincidental common name selection 
> You mean the allow unintended sharing?

> 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.


More information about the es-discuss mailing list