Hey Allen,
The use case runs something like this:
Suppose you use a collection library which has 'filter' implemented on all
of their collections. So we have Set.prototype.filter, Map.prototype.filter,
Tree.prototype.filter, etc. But the library doesn't add Array.filter because
monkey patching is bad.
In your own code, you use a mix of the library collections and Arrays, and
you want to use filter on all of your collections.
So you want to say something like:
{
var buttons = ...; // some Set
var listItems = ...; // some Array
buttons.filter(...); // filter works on Set ...
listItems.filter(...); /// ... and filter works on Arrays in the same
scope.
}
On Mon, Mar 21, 2011 at 6:17 PM, Allen Wirfs-Brock <[email protected]>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. 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.
>
> Allen
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
