set.delete method name
khs4473 at gmail.com
Wed Feb 29 08:18:20 PST 2012
Clearly there is intrest out there for shimming these collection classes in
right now. It would seem prudent to hold off until they are part of a
finished spec though. Or not? Any advise from committee members regarding
On Wed, Feb 29, 2012 at 10:26 AM, David Herman <dherman at mozilla.com> wrote:
> On Feb 28, 2012, at 4:22 PM, Yehuda Katz wrote:
> However, this means that all downstream users would need to use ['delete']
> something that is sufficiently weird and confusing to new developers that
> we always avoid it.
> Which should be enough reason for us to avoid it in standard libraries as
> well. There's really no strong reason for "delete" other than for
> consistency with the delete operator and the existing objects-as-tables
> usage pattern. But given the costs -- small though they may be in
> character-count terms -- any savings in mental cost you get from the
> consistency with the unary operator are more than offset by the mental cost
> of "whoa, you mean I can't write map.delete because some browsers I'm not
> testing with will break?"
> It occurs to me that if Maps are available, so are proxies, but I'm not
> sure I want to start using proxies as a blunt force instrument.
> Well, that's overkill; you can easily create an object that delegates to a
> map without reaching for proxies.
> But that's neither here nor there. You're right; there's not enough upside
> for `delete` compared to the downside of being fragile across browser
> versions and requiring people to pollute their code indefinitely.
> (Note that I *don't* think this is a problem for the `throw` method of
> generators, since if you know you have a browser that supports generators,
> you know you have a browser that supports IdentifierName keywords.)
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss