Could "delete" methods rename to "remove"?
As Allen has said in the past: "The future is bigger than the past". The method name "delete" is compatible with the previous version of the specification—which is not at all ambiguous or underspecified w/r to Identifier and IdentifierName static semantics.
not shold but does work ;-)
Although I agree that specific thing is very inconvenient in some case and minifiers knows this too.
As example, google closure compiler fails with this script in two ways
var wm = new WeakMap;
wm.delete(Object);
Simple minification does the right, resulting in an IE8 safe script suchwm['delete'](Object) thing but it throws a warning:
JSC_INVALID_ES3_PROP_NAME: Keywords and reserved words are not allowed as
unquoted property names in older versions of JavaScript. If you are
targeting newer versions of JavaScript, set the appropriate language_in
option. at line 2 character 3
wm.delete(Object);
While in advance mode and no special flags it just breaks resulting in:
(new WeakMap).a(Object);
YUI is not even able to minify that script ... in few words developers tools do not make the usage of these methods in ES6 collections easy to write and use for developers themselves so tey have to remember those square brackets ... pretty silly if you ask me ^_^
ES6#del() or remove() would have been way easier solution ... choosing a reserved word was OKish, but was also asking for few extra gotchas/troubles nobody really needed/wanted.
The good part is: nobody will care about IE8 anymore ... and pretty soon!!! Still tools should be smarter about this issue
Best
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20131217/c83b269d/attachment
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20131218/2b07394b/attachment
IE6 ? ... I don't understand your argument. We are talking about IE8 and polyfills that work already plus this does not solve the main problem which is about tools not always compatible with ES6 and/or future proof and shim aware.
If tools were OK you wuld just write wm.delete(obj); and the tool would wrap that for you instead of throwing as these might do today.
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20131218/84f8c2c5/attachment
That's why my first hint was .del() as it is in Python and makes sense since ever and it could have made perfect sense in JS too, also as alias for .delete() while transitioning from ES3 legacy, ES5 quirk engines, and ES.next
That being said, I was simply warning that tools might break so this is not just a developer problem but a tooling problem too.
I would not change direction now about .delete() it's too late, shims are out, and it makes sense for everything but IE8 (I don't care about IE8 on mobile so I am selfishly OK with that :P)
So mine was a double warning plus some thoughts on possible different directions the method name could have taken.
On 17 December 2013 18:59, Andrea Giammarchi <andrea.giammarchi at gmail.com>wrote:
While in advance mode and no special flags it just breaks resulting in:
(new WeakMap).a(Object);
This is not related to it being a reserved word: Closure compiler will rename anything that isn't quoted or declared in an externs file. The standard externs files presumably don't declare WeakMap yet, so that's why it's getting renamed.
Nick
You may not care about IE8, but many developers in the world MUST care about it.
What I suggest is to help ES6 be faster to adopt, you know most team in companies are conservative to edge tech, that's why we need es5-shim or es6-shim projects.
It's too bad to write map['delete'], and you can't force all module authors write like that. Tools are helpful, but as Andrea point out, many tools are broken on reserved word up to now.
And I think "remove" is a better name because Java/C# collections all use it.
In fact, I don't care about whether it name remove or del, but just dont name it "delete", such name just trouble the developers who want to migrate to ES6 step by step.
ADVANCED mode requires property definitions for external properties. There aren't ES6 definitions in the default externs for Map or other new features.
An HTML attachment was scrubbed... URL: esdiscuss/attachments/20131218/3d52ceb5/attachment
On Tue, Dec 17, 2013 at 10:17 PM, Shijun He <hax.sfo at gmail.com> wrote:
You may not care about IE8, but many developers in the world MUST care about it.
What I suggest is to help ES6 be faster to adopt, you know most team in companies are conservative to edge tech, that's why we need es5-shim or es6-shim projects.
Right, and map["delete"](key) works fine. The future of the language itself
should not be impaired by a browser that has an expiration date.
It's too bad to write
map['delete'], and you can't force all module authors write like that. Tools are helpful, but as Andrea point out, many tools are broken on reserved word up to now.And I think "remove" is a better name because Java/C# collections all use it.
In fact, I don't care about whether it name remove or del, but just dont name it "delete", such name just trouble the developers who want to migrate to ES6 step by step.
The proposed collection APIs have been public for years with a delete method. It's really not as bad as you're making seem, please be objective.
On Wed, Dec 18, 2013 at 11:30 AM, Rick Waldron <waldron.rick at gmail.com>wrote:
Right, and
map["delete"](key)works fine. The future of the language itself should not be impaired by a browser that has an expiration date.
No, it does NOT work. Because you can't ask all module/library authors write like that. And that means even such modules should be work in old browsers with ES6-shim, they actually fail just because a simple name problem.
And, ES6 and any future version of this language already impaired by legacy
browsers. For example, typeof null MUST be 'object'.
The proposed collection APIs have been public for years with a delete method. It's really not as bad as you're making seem, please be objective.
Yes they are here for years, but most JS devs never know about it. And I am sure I can represent some of them.
On Wed, Dec 18, 2013 at 11:28 AM, Alex Kocharin <alex at kocharin.ru> wrote:
How can you migrate to ES6 if you didn't even migrate to ES5 first?
Even IE5 (pre-ES3) can use string.prototype.repeat with simple shim.
And with es6 shim, Map/Set SHOULD works on IE5, and all modules depend on Map/Set (but not depend on complex features such as Proxy) also works.
So that's what I mean migration step by step. Some of your codes migrate to ES6 API, but keep working on legacy browsers. It's very important for real products. Or migration is totally impossible until 2023 if all pre-ES6 browsers disappear it that time.
On Tue, Dec 17, 2013 at 10:45 PM, Shijun He <hax.sfo at gmail.com> wrote:
No, it does NOT work. Because you can't ask all module/library authors write like that.
Submit patches—libraries intended for use in IE8 should be made to support that platform, it's that simple.
And, ES6 and any future version of this language already impaired by legacy browsers. For example, typeof null MUST be 'object'.
Wrong—that impairment has nothing to do with browsers, but with existing code that makes incorrect assumptions (or none at all) about the return value of typeof.
On Tue, Dec 17, 2013 at 11:02 PM, Shijun He <hax.sfo at gmail.com> wrote:
Even IE5 (pre-ES3) can use string.prototype.repeat with simple shim.
And with es6 shim, Map/Set SHOULD works on IE5, and all modules depend on Map/Set (but not depend on complex features such as Proxy) also works.
I doubt it. paulmillr/es6-shim/blob/master/es6-shim.js#L30-L34
So that's what I mean migration step by step. Some of your codes migrate to ES6 API, but keep working on legacy browsers. It's very important for real products. Or migration is totally impossible until 2023 if all pre-ES6 browsers disappear it that time.
I estimate the new version of ECMAScript will be either 9 or 10 in 2023 ;)
On Wed, Dec 18, 2013 at 1:55 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
Submit patches—libraries intended for use in IE8 should be made to support that platform, it's that simple.
Submitting patches is irrelevant and impractical here.
Why use es5-shim? Because we want to use some scripts written in es5 WITHOUT asking the authors change their code. Though sometimes es5-shim is not enough (for those rely on getter/setter syntax or Object.create(null) which hard to shim).
What I'm talking about is: there will be many modules using ES6 API but still can be used in ES5 or pre-ES5 or even pre-ES3 environment with es5/es6 shims (if they do not rely on the complex features like Proxy or Generator). So bordering the original authors to change their code from a.delete() to a['delete'] are meaningless and I don't expect they will accept such "patch". (Do anyone really think change a.delete to a['delete'] is a patch?)
Wrong—that impairment has nothing to do with browsers, but with existing code that makes incorrect assumptions (or none at all) about the return value of typeof.
I don't see any difference here. Whether it's correct or incorrect assumption, the spec can not change that behavior. In my opinion, using reserved words as methods name in standard library is far more problematic than the case of typeof null (because I don't know any real product code rely on typeof null === 'object' and if any it's very easy to fix).
Le 17/12/2013 22:52, Alex Kocharin a écrit :
I believe ecmascript isn't versionless yet like html is, and that number means something.
As far as I'm concerned, ECMAScript is versionless. As versionless as HTML. Implementation aren't monolithically moving from one standard version to the other. I don't believe we've ever seen a browser with exactly ES3 or exactly ES5 (wait... maybe IE10?! but with IE11, they're back to "ES5+some ES6 features") Modulo spec bugs and history details, version n is fully backward-compatible with version n-1. TC39 decided to move to a more iterative spec release schedule recently too. The version has also never been exposed to the runtime which encourages people to do "version-agnostic feature detection".
Version numbers mean nothing. Version numbers are kept only for the same reason W3C produces "HTML5" and 5.1 and 6 spec. And I think the reason is that most people aren't used to how the web works and are reassured with classic versioning systems... so reassured some people pay a different price to the same company when they're sold a HTML4 site or an HTML5 site (because 5 > 4, you know...). True story.
Maybe versions is just better marketing because "in the next version" suggests a stronger progress than "in the next iteration"?
There are some methods using reserved word "delete", such as Map.prototype.delete, Set.prototype.delete... Though it is allowed since ES5, I think we'd better avoid it because it cause es6 shim solution fail on legacy browsers such as IE8.