set.delete method name
+1
had same thoughts when I wrote this: WebReflection/es6-collections
then I have realized older IE compatibility requires the usage of the string but I would have rather suggested
del
instead of remove so get, set, has, del ... all 3 chars, no problems with reserved keywords
br
It would be tragic to determine future APIs based on broken implementations of historic/archaic browsers - especially in an age where the browser isn't the only "client" of the spec.
to me "del" was simply good enough, at least as fallback
JS avoids cybercrud names where possible, following Java which followed Smalltalk. But we do prefer concise verb-only methods where possible (no Kingdom of Nouns AbstractFactoryFactoryImpl names as in real-world Java; Smalltalk is better precedent but message selectors can afford to be more verbose when strung together than a single method name in JS should be).
So 'del' is too short. We had remove at some point, could go back to it. That seems like the best all-around name.
Thinking of collection protocols with suites of methods that have canonical names (get, force, set, has, remove) helps.
remove is OK too, I proposed del 'cause used already in Python and probably others and it's just a shortcut for the action ... I would mind an "escape" button in my keyboard :-)
br
I feel strongly that "delete" is the right name for this. Currently, all the method names (get, set, has, delete) relate directly to the names associated with these operations when applied to properties, making them more mnemonic.
The need to say collection'delete' rather than collection.delete(...) is only a temporary measure until the ES3 browsers fade out enough to either 1) be ignored, or 2) be supported only as the target of an ES5/6 -> ES3 translation. Granted this will take years. But
we'll be living with these choices for many more years after that.
Agreed, my "remove is the best all-around name" was biased toward the past. We can hang tough. This isn't a huge hardship. Indeed way back in 1996 when Nick Thompson and I connected JS and Java at Netscape, some Java APIs required, e.g. file'delete' instead of file.delete(). I wish I had not reserved property names in '95. Fixed in ES5!
Are the Set, Map, etc types going to be implemented in any engine that doesn't already have ES5 unreserved property name semantics?
Or are we talking about implementing shims in non-ES6 engines (and so possibly ES<5)?
I was talking about shims.
PEter
In many languages normally delete means destruction of the value and remove is used where the value is extracted from a list but the value remains.
El 12/02/2012, a las 22:43, Mark S. Miller escribió:
mainly me too, and I also agree delete is the right word for that over remove.
I would probably go for "del" as enhanced API for code that should run across browsers ... my main concern is that shims sometimes make developers believe "that's the way" ( as libraries do in any case )
br
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
I agree that it should be named "remove" rather than delete.
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".
I appreciate the feedback, but I do not understand the rationale.
The rationale I found compelling from upthread was that "remove" is a more apt antonym to "add".
To compare, "delete"'s natural counterpart would be "put".
I don't think we should care about old brosers when building ES 6. People won't use just one part of it. They'll use all of it or just stick with ES 5/3.
Plus there will be transpilers and replacing ".delete" by "['delete']" isn't hard...
Sent from my smartphone.
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".
I can easily see frameworks, a shim, or vendors widely adding code such as the following.
Map.prototype.remove = function(elm) { this'delete'; };
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.
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'?
I agree add/remove is more semantic as put/delete would be. 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";
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
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";
...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.
On Feb 28, 2012, at 12:53 PM, Xavier MONTILLET wrote:
I don't think we should care about old brosers when building ES 6. People won't use just one part of it. They'll use all of it or just stick with ES 5/3.
I'm afraid this is simply false.
On Wed, Feb 29, 2012 at 9:52 AM, Rick Waldron <waldron.rick at gmail.com>wrote:
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
+1 in agreement here.
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";
...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.
We should not underestimate the amount of help that shims have been for moving real world development towards standards. Its nice to be principled about how it shouldn't matter with correct implementations, but if we can make the transition easier why not? If people are forced to build their own abstractions (instead of just shims) then it creates problems with needing certain libraries, or having differences between libraries. Sometimes its inevitable, but here I see no gain for keeping it delete.
On Feb 28, 2012, at 4:22 PM, Yehuda Katz wrote:
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.
Which should be enough reason for us to avoid it in standard libraries as well. There's really no strong reason for "delete" other than for consistency with the delete operator and the existing objects-as-tables usage pattern. But given the costs -- small though they may be in character-count terms -- any savings in mental cost you get from the consistency with the unary operator are more than offset by the mental cost of "whoa, you mean I can't write map.delete because some browsers I'm not testing with will break?"
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.
Well, that's overkill; you can easily create an object that delegates to a map without reaching for proxies.
But that's neither here nor there. You're right; there's not enough upside for delete compared to the downside of being fragile across browser versions and requiring people to pollute their code indefinitely.
(Note that I don't think this is a problem for the throw method of generators, since if you know you have a browser that supports generators, you know you have a browser that supports IdentifierName keywords.)
Clearly there is intrest out there for shimming these collection classes in right now. It would seem prudent to hold off until they are part of a finished spec though. Or not? Any advise from committee members regarding optimistic shimming?
khs
The Set proposal has a "delete" method. Old ECMAScript implementations do not allow "delete" to appear as a bare method name like set.delete('foo') and it is necessary to write the awkward set'delete'. Because of this and knowing polyfills will be written to support Set in older implementations, would it be better to choose "remove" as the method name so that set.remove('foo') can be written in the older implementations? I think this would save a lot of unnecessary debugging for cross-browser programming.
Peter
The Set proposal has a "delete" method. Old ECMAScript implementations do not allow "delete" to appear as a bare method name like set.delete('foo') and it is necessary to write the awkward set['delete']('foo'). Because of this and knowing polyfills will be written to support Set in older implementations, would it be better to choose "remove" as the method name so that set.remove('foo') can be written in the older implementations? I think this would save a lot of unnecessary debugging for cross-browser programming. Peter