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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
