I can easily see frameworks, a shim, or vendors widely adding code
such as the following.
Map.prototype.remove = function(elm) {
this['delete'](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 <wyc...@gmail.com> 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 <a...@ashannon.us> 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
>> http://ashannon.us
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Cheers,
> --MarkM
--
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. & Mathematics
http://ashannon.us
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
