On Mar 21, 2011, at 9:40 PM, Brendan Eich <bren...@mozilla.com> wrote:
> 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).
There would be several private names per type though each one preventing any
occurrence of that name within any identifier in any member expression at that
scope. This would complicate things like minifiers. Not to mention trying to
mix say svg, canvas and Dom within some framework since they all use common
member names such as element, node, children, attributes, etc.
>
> 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
> 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
