set.delete method name
Rick Waldron
waldron.rick at gmail.com
Wed Feb 29 06:52:22 PST 2012
Despite my comments about not letting archaic browsers dictate our future,
which still stands...
On Wed, Feb 29, 2012 at 3:40 AM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:
> I agree add/remove is more semantic as put/delete would be.
I also complete agree with the intuitiveness of add/remove over add/delete
> I also said that m.delete is problematic for shims, not because of missing
> m["delete"] possibility, simply because it looks really ugly to
>
> m.add(stuff);
> m["delete"](stuff);
>
...But you would never have to do this in any browser that has correctly
implemented *Identifier, **IdentifierName *and* ReservedWord *semantics.
Non-Browser JS can implement this with minimal, if not zero, adverse effect.
>
> 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.
>
> br
>
>
> On Wed, Feb 29, 2012 at 7:08 AM, Brendan Eich <brendan at mozilla.org> 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 ashannon.us<mailto:
>>> adam at 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 <tel: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 at mozilla.org <mailto:es-discuss at mozilla.org**>
>>>
>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> --MarkM
>>> ______________________________**_________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120229/4c462b0a/attachment.html>
More information about the es-discuss
mailing list