set.delete method name

Adam Shannon adam at
Tue Feb 28 18:50:01 PST 2012

I can easily see frameworks, a shim, or vendors widely adding code
such as the following.

Map.prototype.remove = function(elm) {

Which should easily convince anyone that .remove() is better for the
end user than ['delete'](). Delete already has a meaning outside of
Maps or Sets, and is only introducing unneeded complexity to something
as simple as a Collection.

On Tue, Feb 28, 2012 at 18:22, Yehuda Katz <wycats at> wrote:
> Let me explain my use-case a bit more. Ember exposes an Ember.Map class that
> downstream users (the framework, but also app developers) can use when they
> want maps with arbitrary keys. I explained the implementation a bit
> upthread.
> Ideally, I would like to be able to do something like Ember.Map = Map if ES6
> maps are available, since we fashioned our map API intentionally after the
> ES6 API.
> 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.
> 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.
> Sent from my Windows Phone
> ________________________________
> From: Mark S. Miller
> Sent: 2/28/2012 11:54 AM
> To: Adam Shannon
> Cc: Yehuda Katz; es-discuss
> Subject: Re: set.delete method name
> 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? 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> 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
>> --
>> Adam Shannon
>> Developer
>> University of Northern Iowa
>> Sophomore -- Computer Science B.S. & Mathematics
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> --
>     Cheers,
>     --MarkM

Adam Shannon
University of Northern Iowa
Sophomore -- Computer Science B.S. & Mathematics

More information about the es-discuss mailing list