set.delete method name

[Rick Waldron]

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>