Lexically Scoped Object Extensions (was About private names)

Brendan Eich brendan at mozilla.com
Mon Mar 21 21:40:04 PDT 2011


On Mar 21, 2011, at 6:17 PM, Allen Wirfs-Brock wrote:

> On Mar 21, 2011, at 5:55 PM, Waldemar Horwat wrote:
> 
>> You'd still run into all of the issues caused by "private filter" behaving like a C++ #define.

#define exagerrates.


>>  For example:
>> 
>> var foo = {filter: 34};
>> then pass foo to an outside client.
> 
> Trying to interpret your comment.  Are you saying that the above appearing within the scope of the "private filter" would unintentionally use private foo instead of public foo?
> 
> That's true, but the whole point of the block  (and the extension declaration) was to constrain the visibility of private filter, so it could be used as an extension property name in a limited scope.  Defining a property using that name within that scope seem like a pretty clueless error.  Sure, it will happen, but I don't see how this use of lexically scoping is any more or less error prone an any other use.

You could be right. But there is a difference, it is not as extreme as #define, but it's real. It is what Andrew described so clearly: that any foo after any dot in the scope of private foo is bound to the private name.

With let, const, or function in block, the lexical scoping affects the meaning of unqualified identifiers as primary expressions. It doesn't affect the meaning of identifiers (IdentifierName in the grammar) on the right of '.' in MemberExpressions.

Does this matter? In Java it matters much less because of types. In JS, it matters more but an IDE could still help (as in Java, but without types -- just lexical use-to-def connection-making by the IDE).

I'm not saying this characteristic of private names is "bad" or "good". It is distinct from lexical binding in Harmony without private names, though.

/be


More information about the es-discuss mailing list