set.delete method name

Andrea Giammarchi andrea.giammarchi at
Wed Feb 29 00:40:25 PST 2012

I agree add/remove is more semantic as put/delete would be.
I also said that m.delete is problematic for shims, not because of missing
m["delete"] possibility, simply because it looks really ugly to


not natural to write. It is true that ES6 does not bring only harmony
collections so other problems can't be solved without transpiler in any
case, but Map, as example, could be used already without problems so
ES3/5/6 hybrid libraries, as Ember could be, as well as underscore, may
take advantage of what's shimmable.

I also see already

Map.prototype.remove = Map.prototype["delete"];

all over the web ...
I am lucky enough to work with mobile browsers and no problems there with
.delete but unfortunately out there there are still too many developers
that must somehow support IE8 or even 7.

These developers may start using some ES6 shim today, so the earlier we do
it right, the later we gonna have problems :-)

My 2 cents.


On Wed, Feb 29, 2012 at 7:08 AM, Brendan Eich <brendan at> wrote:

> Mark S. Miller wrote:
>> I appreciate the feedback, but I do not understand the rationale. Is it
>> just to avoid needing to say
>>    map['delete'](key)
>> when supporting old browsers without an ES5->ES3 translation step?
> Yes. Isn't that enough friction? I think so based on long-standing pain
> that led us to unreserve keywords after dot.
> I'm still open to remove because it's a better antonym to add. I do not
> think the base-level operator names (where they exist) must be re-used. But
> I may be missing a fine point here for why you prefer 'delete'?
> /be
>  If there is no other downside, I'm inclined to stick with "delete".
>> On Tue, Feb 28, 2012 at 11:49 AM, Adam Shannon <adam at <mailto:
>> adam at>> wrote:
>>    I agree that it should be named "remove" rather than delete.
>>    On Tuesday, February 28, 2012, Yehuda Katz wrote:
>>        Just catching up on this discussion. I should point out that
>>        this problem applies to Map and possibly other collections as
>>        well.
>>        Speaking as someone who is looking to use these features
>>        today, I hit this problem immediately. Ember.js already has a
>>        Map; we can reliably generate a unique id for any object (by
>>        stashing it on the object; ok for our cases), and have a
>>        reliable way to generate guids for non-Objects.
>>        Ideally, we'd like to be able to say something like:
>>        `if(typeof Map !== "undefined") { Ember.Map = Map; }`
>>        (although we'd probably do more checks because shims in
>>        general have worse performance characteristics).
>>        Unfortunately, because of the `delete` problem, we cannot do
>>        this. Because we are unwilling to monkey-patch Map directly,
>>        we will have to create a shim object that delegates to the Map.
>>        I'm sympathetic to the "let's not make choices based on old
>>        broken browsers", but let's be fair here. The name `remove` is
>>        perfectly clear. In five years, nobody is going to think twice
>>        about that API, and web developers won't think twice about it
>>        today. Using a clear name that also happens not to run afoul
>>        of older browsers for shim purposes isn't caving to the past:
>>        it's being pragmatic about helping people adopt a new feature
>>        with very little cost.
>>        Yehuda Katz
>>        (ph) 718.877.1325 <tel:718.877.1325>
>>    --     Adam Shannon
>>    Developer
>>    University of Northern Iowa
>>    Sophomore -- Computer Science B.S. & Mathematics
>>    ______________________________**_________________
>>    es-discuss mailing list
>>    es-discuss at <mailto:es-discuss at**>
>> --
>>    Cheers,
>>    --MarkM
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list