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 < [email protected]> 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 <[email protected]> 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 <[email protected]<mailto: >>> [email protected]>> 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 >>> [email protected] <mailto:[email protected]**> >>> >>> >>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>> >>> >>> >>> >>> -- >>> Cheers, >>> --MarkM >>> ______________________________**_________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >>> >> ______________________________**_________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
