Could delete methods rename to remove?
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. -- hax ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
Le 17/12/2013 10:19, Shijun He a écrit : 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. Note that there is a warning [1] (maybe arguably). Among other incompatibilities, size is a getter too. myMap.delete fails, but myMap['delete'] should work. David [1] https://github.com/paulmillr/es6-shim/blob/4322eae20b6f8a7769fa1d89ac207ef8ee9e1ee4/es6-shim.js#L662 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
On Tue, Dec 17, 2013 at 4:19 AM, Shijun He hax@gmail.com wrote: 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. 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. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On Mon, Dec 16, 2013 at 6:06 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: last thought would be an answer to th epossible question: do we need to support mozMatchSelector forever ? NO since matches() will do once it works as standards say No, that's not how it works. You support something as long as significant amounts of content depend on it, so you don't break pages. The existence of a replacement doesn't mean that everyone immediately updates their pages to the new method. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
sorry what ? https://github.com/WebReflection/es6-collections#es6-harmony-collections-fast-polyfill https://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js https://github.com/Benvie/ES6-Harmony-Collections-Shim https://github.com/paulmillr/es6-shim https://gist.github.com/Gozala/1269991 regards On Tue, Dec 17, 2013 at 11:38 AM, Alex Kocharin a...@kocharin.ru wrote: ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, Andrea Giammarchi andrea.giammar...@gmail.com: 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 ```javascript var wm = new WeakMap; wm.delete(Object); ``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 Regards On Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote: Le 17/12/2013 10:19, Shijun He a écrit : 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. Note that there is a warning [1] (maybe arguably). Among other incompatibilities, size is a getter too. myMap.delete fails, but myMap['delete'] should work. David [1] https://github.com/paulmillr/es6-shim/blob/ 4322eae20b6f8a7769fa1d89ac207ef8ee9e1ee4/es6-shim.js#L662 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss , ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
The real-world out there always tries to address the potential standard and use these prefixed methods as fallbacks, not vice versa. It would be very unwise to rely prefixed methods only in production and I am not sure who does it but yes, the dropping might be gradual notifying in console that has been deprecated. Having the same unstable, not standard yet, global native constructor is a problem in these fields: 1. documentation ... MDN has been promoted as the place to document JavaScript ... MDN has many Mozilla and Gecko only methods and properties ... does MDN want to include every possible quirk for every possible method that every browser might or might not have implemented in a slightly different, since not standard yet, way? If the answer is NO, it's fragmentation of the documentation ... which I believe is not useful for anyone 2. User Agent sniffing will be promoted instead of impossible features detections 3. signatures implemented too early will lead to shenanigans 4. every early implementation either will break the web the day it will change or will create an absurd mess of extra code to understand if it's the one that works as expected or not (again, leads to UA sniffing) A very concrete example about prefixes, and since you work on this daily, is the CSS gradient background syntax: http://css-tricks.com/css3-gradients/ Now imagine that scenario with JavaScript ... a constructor that has different signatures and no way to tell if it was an early adoption or the standard version if not through User Agent sniffing ... and since the race to early adopt any sort of thing is the biggest part of the modern Browsers war, who do you honestly think will benefit from such decision? I understand that at the time Chromium decided to branch out from WebKit, going to the press saying yeah, another blok prefix is coming would have been bad ... press speaking, but at the same time almost nobody uses anymore pure CSS and prefixes there are handled automatically plus many use utilities such lo-dash or others so that behavior are ensured behind the scene and nobody really care if that function was prefixed or not. What do we have as pros avoiding prefixes instead? Does that overcome all these cons? Best Regards On Tue, Dec 17, 2013 at 10:00 AM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Dec 16, 2013 at 6:06 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: last thought would be an answer to th epossible question: do we need to support mozMatchSelector forever ? NO since matches() will do once it works as standards say No, that's not how it works. You support something as long as significant amounts of content depend on it, so you don't break pages. The existence of a replacement doesn't mean that everyone immediately updates their pages to the new method. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
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 ```javascript var wm = new WeakMap; wm.delete(Object); ``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 Regards On Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote: Le 17/12/2013 10:19, Shijun He a écrit : 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. Note that there is a warning [1] (maybe arguably). Among other incompatibilities, size is a getter too. myMap.delete fails, but myMap['delete'] should work. David [1] https://github.com/paulmillr/es6-shim/blob/ 4322eae20b6f8a7769fa1d89ac207ef8ee9e1ee4/es6-shim.js#L662 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
You can't run any ES6 script in a browser that don't support ES6, because they will throw syntax error at the first yield (unless you're using compiler like traceur, but it won't have a problem with getting .delete work either). If you use shims, that's fine, but you're not writing ES6, you're writing ES5+shims, and that's not ES6 because you can't use all the features it introduces. I believe ecmascript isn't versionless yet like html is, and that number means something. If you want to support IE6 without compiling, fine, you can write in ES3+shims using wm['delete'](object) syntax. I don't see it being an issue. 18.12.2013, 00:59, "Andrea Giammarchi" andrea.giammar...@gmail.com:sorry what ? https://github.com/WebReflection/es6-collections#es6-harmony-collections-fast-polyfillhttps://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.jshttps://github.com/Benvie/ES6-Harmony-Collections-Shimhttps://github.com/paulmillr/es6-shimhttps://gist.github.com/Gozala/1269991 regards On Tue, Dec 17, 2013 at 11:38 AM, Alex Kocharin a...@kocharin.ru wrote: ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, "Andrea Giammarchi" andrea.giammar...@gmail.com: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 ```_javascript_var wm = new WeakMap;wm.delete(Object);``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 RegardsOn Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote:Le 17/12/2013 10:19, Shijun He a écrit :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.Note that there is a warning [1] (maybe arguably). Among other incompatibilities, "size" is a getter too. myMap.delete fails, but myMap['delete'] should work. David [1] https://github.com/paulmillr/es6-shim/blob/4322eae20b6f8a7769fa1d89ac207ef8ee9e1ee4/es6-shim.js#L662 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss,___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, "Andrea Giammarchi" andrea.giammar...@gmail.com: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 ```_javascript_var wm = new WeakMap;wm.delete(Object);``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 RegardsOn Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote:Le 17/12/2013 10:19, Shijun He a écrit :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.Note that there is a warning [1] (maybe arguably). Among other incompatibilities, "size" is a getter too. myMap.delete fails, but myMap['delete'] should work. David [1] https://github.com/paulmillr/es6-shim/blob/4322eae20b6f8a7769fa1d89ac207ef8ee9e1ee4/es6-shim.js#L662 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss,___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
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. Regards On Tue, Dec 17, 2013 at 1:52 PM, Alex Kocharin a...@kocharin.ru wrote: You can't run any ES6 script in a browser that don't support ES6, because they will throw syntax error at the first yield (unless you're using compiler like traceur, but it won't have a problem with getting .delete work either). If you use shims, that's fine, but you're not writing ES6, you're writing ES5+shims, and that's not ES6 because you can't use all the features it introduces. I believe ecmascript isn't versionless yet like html is, and that number means something. If you want to support IE6 without compiling, fine, you can write in ES3+shims using wm['delete'](object) syntax. I don't see it being an issue. 18.12.2013, 00:59, Andrea Giammarchi andrea.giammar...@gmail.com: sorry what ? https://github.com/WebReflection/es6-collections#es6-harmony-collections-fast-polyfill https://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js https://github.com/Benvie/ES6-Harmony-Collections-Shim https://github.com/paulmillr/es6-shim https://gist.github.com/Gozala/1269991 regards On Tue, Dec 17, 2013 at 11:38 AM, Alex Kocharin a...@kocharin.ru wrote: ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, Andrea Giammarchi andrea.giammar...@gmail.com: 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 ```javascript var wm = new WeakMap; wm.delete(Object); ``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 Regards On Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote: Le 17/12/2013 10:19, Shijun He a écrit : 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. Note that there is a warning [1] (maybe arguably). Among other incompatibilities, size is a getter too. myMap.delete fails, but myMap['delete'] should work. David [1] https://github.com/paulmillr/es6-shim/blob/ 4322eae20b6f8a7769fa1d89ac207ef8ee9e1ee4/es6-shim.js#L662 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss , ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Name of WeakMap
On Tue, Dec 17, 2013 at 12:43 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: The real-world out there always tries to address the potential standard and use these prefixed methods as fallbacks, not vice versa. That's not true. almost nobody uses anymore pure CSS and prefixes there are handled automatically That isn't either. Not even close. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
Well, you said that it works in IE8, and I don't care enough to test it, so said about IE6 because it is the same legacy kind of thing. Doesn't matter. Legacy and broken tools is not a valid reason to avoid perfectly good method name, especially considering the fact that it is a valid ES5 syntax everyone should be supporting for years now. "delete" can't stay a "not a reserved word, but kinda not recommended" forever you know, it doesn't make any sense. It should be named "delete" precisely because keyword was named delete, to make all these operators/functions look alike. Naming it "remove" just creates a confusion for no good reason. 18.12.2013, 02:17, "Andrea Giammarchi" andrea.giammar...@gmail.com: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. Regards On Tue, Dec 17, 2013 at 1:52 PM, Alex Kocharin a...@kocharin.ru wrote: You can't run any ES6 script in a browser that don't support ES6, because they will throw syntax error at the first yield (unless you're using compiler like traceur, but it won't have a problem with getting .delete work either). If you use shims, that's fine, but you're not writing ES6, you're writing ES5+shims, and that's not ES6 because you can't use all the features it introduces. I believe ecmascript isn't versionless yet like html is, and that number means something. If you want to support IE6 without compiling, fine, you can write in ES3+shims using wm['delete'](object) syntax. I don't see it being an issue. 18.12.2013, 00:59, "Andrea Giammarchi" andrea.giammar...@gmail.com:sorry what ? https://github.com/WebReflection/es6-collections#es6-harmony-collections-fast-polyfillhttps://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.jshttps://github.com/Benvie/ES6-Harmony-Collections-Shimhttps://github.com/paulmillr/es6-shimhttps://gist.github.com/Gozala/1269991 regards On Tue, Dec 17, 2013 at 11:38 AM, Alex Kocharin a...@kocharin.ru wrote: ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, "Andrea Giammarchi" andrea.giammar...@gmail.com: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 ```_javascript_var wm = new WeakMap;wm.delete(Object);``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 RegardsOn Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote:Le 17/12/2013 10:19, Shijun He a écrit :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.Note that there is a warning [1] (maybe arguably). Among other incompatibilities, "size" is a getter too. myMap.delete fails, but myMap['delete'] should work. David [1] https://github.com/paulmillr/es6-shim/blob/4322eae20b6f8a7769fa1d89ac207ef8ee9e1ee4/es6-shim.js#L662 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss,___es-discuss mailing listes-discuss@mozilla.orghttps://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss___ es-discuss mailing list
Re: Could delete methods rename to remove?
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. Cheers On Tue, Dec 17, 2013 at 2:53 PM, Alex Kocharin a...@kocharin.ru wrote: Well, you said that it works in IE8, and I don't care enough to test it, so said about IE6 because it is the same legacy kind of thing. Doesn't matter. Legacy and broken tools is not a valid reason to avoid perfectly good method name, especially considering the fact that it is a valid ES5 syntax everyone should be supporting for years now. delete can't stay a not a reserved word, but kinda not recommended forever you know, it doesn't make any sense. It should be named delete precisely because keyword was named delete, to make all these operators/functions look alike. Naming it remove just creates a confusion for no good reason. 18.12.2013, 02:17, Andrea Giammarchi andrea.giammar...@gmail.com: 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. Regards On Tue, Dec 17, 2013 at 1:52 PM, Alex Kocharin a...@kocharin.ru wrote: You can't run any ES6 script in a browser that don't support ES6, because they will throw syntax error at the first yield (unless you're using compiler like traceur, but it won't have a problem with getting .delete work either). If you use shims, that's fine, but you're not writing ES6, you're writing ES5+shims, and that's not ES6 because you can't use all the features it introduces. I believe ecmascript isn't versionless yet like html is, and that number means something. If you want to support IE6 without compiling, fine, you can write in ES3+shims using wm['delete'](object) syntax. I don't see it being an issue. 18.12.2013, 00:59, Andrea Giammarchi andrea.giammar...@gmail.com: sorry what ? https://github.com/WebReflection/es6-collections#es6-harmony-collections-fast-polyfill https://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js https://github.com/Benvie/ES6-Harmony-Collections-Shim https://github.com/paulmillr/es6-shim https://gist.github.com/Gozala/1269991 regards On Tue, Dec 17, 2013 at 11:38 AM, Alex Kocharin a...@kocharin.ru wrote: ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, Andrea Giammarchi andrea.giammar...@gmail.com: 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 ```javascript var wm = new WeakMap; wm.delete(Object); ``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 Regards On Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote: Le 17/12/2013 10:19, Shijun He a écrit : 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
Re: Name of WeakMap
Are you able to provide Pros of the non prefixed decision or that's all you have to say about it? Not even a link? How useful has your answer been for anyone? Which library uses window.webkitRequestAnimationFrame before window.requestAnimationFrame and why nobody filed a bug until now? Plus I am one of those that hand-craft CSS withe prefixes included and I am happy to deal with prefixes ... which developer uses prefixes everywhere on daily basis without tools? 'cause at least I try to group via classes and use as less as possible. Thanks On Tue, Dec 17, 2013 at 2:41 PM, Jason Orendorff jason.orendo...@gmail.comwrote: On Tue, Dec 17, 2013 at 12:43 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: The real-world out there always tries to address the potential standard and use these prefixed methods as fallbacks, not vice versa. That's not true. almost nobody uses anymore pure CSS and prefixes there are handled automatically That isn't either. Not even close. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Object.assign with several source objects
Hello,
Tonight, when playing with ES6’s new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2), ...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) {
var params = Object.assign({ method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
[target, s1, s2, s3].reduce(function(p, c){
return Object.assign(p, c);
});
On Tue, Dec 17, 2013 at 5:06 PM, Claude Pache claude.pa...@gmail.comwrote:
Hello,
Tonight, when playing with ES6’s new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2), ...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) {
var params = Object.assign({ method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
P.S. actually, that is the equivalent of `[target, s1, s2,
s3].reduce(Object.assign);` but I was not sure it accept extra arguments too
On Tue, Dec 17, 2013 at 5:16 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
[target, s1, s2, s3].reduce(function(p, c){
return Object.assign(p, c);
});
On Tue, Dec 17, 2013 at 5:06 PM, Claude Pache claude.pa...@gmail.comwrote:
Hello,
Tonight, when playing with ES6’s new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2), ...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) {
var params = Object.assign({ method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
FWIW I don't see any other usage for extra arguments neither
On Tue, Dec 17, 2013 at 5:17 PM, Brendan Eich bren...@mozilla.com wrote:
It's now or never. I agree multiple sources are useful enough to do now; I
don't see a different third parameter that would be precluded by deciding
this. But others may disagree.
/be
Claude Pache mailto:claude.pa...@gmail.com
December 17, 2013 5:06 PM
Hello,
Tonight, when playing with ES6’s new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2),
...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) {
var params = Object.assign({ method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Object.assign with several source objects
Interestingly, if multiple arguments are not added now, they may never be
possible, since there will be so much `[a, b, c].reduce(Object.assign)` code in
the wild that implicitly passes an index as the third parameter and the whole
array as the fourth parameter.
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
Sent: Tuesday, December 17, 2013 20:18
To: Claude Pache
Cc: es-discuss
Subject: Re: Object.assign with several source objects
It's now or never. I agree multiple sources are useful enough to do now; I
don't see a different third parameter that would be precluded by deciding this.
But others may disagree.
/be
Claude Pache mailto:claude.pa...@gmail.com December 17, 2013 5:06 PM
Hello,
Tonight, when playing with ES6's new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2),
...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) { var params = Object.assign({
method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
-Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
Your insight about Andreas's reduce example seals the deal for me.
/be
Domenic Denicola mailto:dome...@domenicdenicola.com
December 17, 2013 5:20 PM
Interestingly, if multiple arguments are not added now, they may never
be possible, since there will be so much `[a, b,
c].reduce(Object.assign)` code in the wild that implicitly passes an
index as the third parameter and the whole array as the fourth parameter.
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Brendan Eich
Sent: Tuesday, December 17, 2013 20:18
To: Claude Pache
Cc: es-discuss
Subject: Re: Object.assign with several source objects
It's now or never. I agree multiple sources are useful enough to do
now; I don't see a different third parameter that would be precluded
by deciding this. But others may disagree.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich mailto:bren...@mozilla.com
December 17, 2013 5:17 PM
It's now or never. I agree multiple sources are useful enough to do
now; I don't see a different third parameter that would be precluded
by deciding this. But others may disagree.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Claude Pache mailto:claude.pa...@gmail.com
December 17, 2013 5:06 PM
Hello,
Tonight, when playing with ES6’s new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2),
...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) {
var params = Object.assign({ method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
—Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
true ... as true is for anything that will ever be passed to reduce that
accept just 2 arguments. Handy in a way, blocking progress in others.
`Object.assing(target, ...[multSources]);`
wins to me
On Tue, Dec 17, 2013 at 5:20 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Interestingly, if multiple arguments are not added now, they may never be
possible, since there will be so much `[a, b, c].reduce(Object.assign)`
code in the wild that implicitly passes an index as the third parameter and
the whole array as the fourth parameter.
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Brendan Eich
Sent: Tuesday, December 17, 2013 20:18
To: Claude Pache
Cc: es-discuss
Subject: Re: Object.assign with several source objects
It's now or never. I agree multiple sources are useful enough to do now; I
don't see a different third parameter that would be precluded by deciding
this. But others may disagree.
/be
Claude Pache mailto:claude.pa...@gmail.com December 17, 2013 5:06 PM
Hello,
Tonight, when playing with ES6's new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2),
...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) { var params = Object.assign({
method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
-Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
the alternative is that the second argument expects an array of 1 to n
source objects. This works with reduce and leaves way clear for future 3rd
argument (eg deep copy boolean)
On Tue, Dec 17, 2013 at 5:24 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
true ... as true is for anything that will ever be passed to reduce that
accept just 2 arguments. Handy in a way, blocking progress in others.
`Object.assing(target, ...[multSources]);`
wins to me
On Tue, Dec 17, 2013 at 5:20 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Interestingly, if multiple arguments are not added now, they may never be
possible, since there will be so much `[a, b, c].reduce(Object.assign)`
code in the wild that implicitly passes an index as the third parameter and
the whole array as the fourth parameter.
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
Brendan Eich
Sent: Tuesday, December 17, 2013 20:18
To: Claude Pache
Cc: es-discuss
Subject: Re: Object.assign with several source objects
It's now or never. I agree multiple sources are useful enough to do now;
I don't see a different third parameter that would be precluded by deciding
this. But others may disagree.
/be
Claude Pache mailto:claude.pa...@gmail.com December 17, 2013 5:06 PM
Hello,
Tonight, when playing with ES6's new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2),
...)`
My use case: I have several objects, used as dictionaries, coming from
different sources, and I want to merge them together. For example:
c.prototype.exec = function(userParams) { var params = Object.assign({
method: GET }, this.defaultParams,
userParams)
// etc.
}
Any thoughts?
-Claude
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
Angus Croll wrote: the alternative is that the second argument expects an array of 1 to n source objects. This works with reduce and leaves way clear for future 3rd argument (eg deep copy boolean) Mandatory array-of-parameters is an anti-pattern, given spread. Even if the allocation costs nothing, the obligatory [ and ] around the most common (singleton) case is a eye-killer. We don't want indefinite future-proofing for argument extension, BTW. We always get in trouble trying to do that, because real code passes trailing args. What we want are fixed arity functions that we never extend, and variadic functions that are variadic from the get-go. I think deep copy is not ever happening, in the same vein. Just say no, KISS, don't leave too much open -- it won't actually pan out. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: License change
Has the specification licensing issue been addressed? What is the result? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
On Tue, Dec 17, 2013 at 8:17 PM, Brendan Eich bren...@mozilla.com wrote:
It's now or never. I agree multiple sources are useful enough to do now; I
don't see a different third parameter that would be precluded by deciding
this. But others may disagree.
A third Properties argument that matches the second Properties argument to
Object.create() and Object.defineProperties
class Cycle {
constructor(details) {
Object.assign(this, details, {
wheels: {
value: details.type === tricycle ? 3 : 2,
configurable: false,
writable: false
}
});
}
}
var trike = new Cycle({
color: red,
type: tricycle
});
... Which doesn't break the reduce pattern since the index would
effectively be meaningless in that context, ie.
Object.getOwnPropertyNames(Object(1)).length === 0;
Anyway...I had originally pushed for Object.assign with multiple sources
and dropped it when consensus seemed to hinge on one target, one source.
The third Properties argument is compelling and doesn't prevent using
Object.assign as a primitive mechanism for library code to build on top of.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
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. On Wed, Dec 18, 2013 at 6:53 AM, Alex Kocharin a...@kocharin.ru wrote: Well, you said that it works in IE8, and I don't care enough to test it, so said about IE6 because it is the same legacy kind of thing. Doesn't matter. Legacy and broken tools is not a valid reason to avoid perfectly good method name, especially considering the fact that it is a valid ES5 syntax everyone should be supporting for years now. delete can't stay a not a reserved word, but kinda not recommended forever you know, it doesn't make any sense. It should be named delete precisely because keyword was named delete, to make all these operators/functions look alike. Naming it remove just creates a confusion for no good reason. 18.12.2013, 02:17, Andrea Giammarchi andrea.giammar...@gmail.com: 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. Regards On Tue, Dec 17, 2013 at 1:52 PM, Alex Kocharin a...@kocharin.ru wrote: You can't run any ES6 script in a browser that don't support ES6, because they will throw syntax error at the first yield (unless you're using compiler like traceur, but it won't have a problem with getting .delete work either). If you use shims, that's fine, but you're not writing ES6, you're writing ES5+shims, and that's not ES6 because you can't use all the features it introduces. I believe ecmascript isn't versionless yet like html is, and that number means something. If you want to support IE6 without compiling, fine, you can write in ES3+shims using wm['delete'](object) syntax. I don't see it being an issue. 18.12.2013, 00:59, Andrea Giammarchi andrea.giammar...@gmail.com: sorry what ? https://github.com/WebReflection/es6-collections#es6-harmony-collections-fast-polyfill https://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js https://github.com/Benvie/ES6-Harmony-Collections-Shim https://github.com/paulmillr/es6-shim https://gist.github.com/Gozala/1269991 regards On Tue, Dec 17, 2013 at 11:38 AM, Alex Kocharin a...@kocharin.ru wrote: ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, Andrea Giammarchi andrea.giammar...@gmail.com: 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 ```javascript var wm = new WeakMap; wm.delete(Object); ``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 Regards On Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote: Le 17/12/2013 10:19, Shijun He a écrit : There are some methods using reserved word delete, such as Map.prototype.delete, Set.prototype.delete... Though it is allowed since ES5, I
Re: Could delete methods rename to remove?
ADVANCED mode requires property definitions for external properties. There aren't ES6 definitions in the default externs for Map or other new features. On Dec 17, 2013 10:59 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: 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 ```javascript var wm = new WeakMap; wm.delete(Object); ``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 Regards On Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote: Le 17/12/2013 10:19, Shijun He a écrit : 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. Note that there is a warning [1] (maybe arguably). Among other incompatibilities, size is a getter too. myMap.delete fails, but myMap['delete'] should work. David [1] https://github.com/paulmillr/es6-shim/blob/ 4322eae20b6f8a7769fa1d89ac207ef8ee9e1ee4/es6-shim.js#L662 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
such name just trouble the developers who want to migrate to ES6 step by step How can you migrate to ES6 if you didn't even migrate to ES5 first? 18.12.2013, 07:17, "Shijun He" hax@gmail.com: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.On Wed, Dec 18, 2013 at 6:53 AM, Alex Kocharin a...@kocharin.ru wrote: Well, you said that it works in IE8, and I don't care enough to test it, so said about IE6 because it is the same legacy kind of thing. Doesn't matter. Legacy and broken tools is not a valid reason to avoid perfectly good method name, especially considering the fact that it is a valid ES5 syntax everyone should be supporting for years now. "delete" can't stay a "not a reserved word, but kinda not recommended" forever you know, it doesn't make any sense. It should be named "delete" precisely because keyword was named delete, to make all these operators/functions look alike. Naming it "remove" just creates a confusion for no good reason. 18.12.2013, 02:17, "Andrea Giammarchi" andrea.giammar...@gmail.com: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. Regards On Tue, Dec 17, 2013 at 1:52 PM, Alex Kocharin a...@kocharin.ru wrote: You can't run any ES6 script in a browser that don't support ES6, because they will throw syntax error at the first yield (unless you're using compiler like traceur, but it won't have a problem with getting .delete work either). If you use shims, that's fine, but you're not writing ES6, you're writing ES5+shims, and that's not ES6 because you can't use all the features it introduces. I believe ecmascript isn't versionless yet like html is, and that number means something. If you want to support IE6 without compiling, fine, you can write in ES3+shims using wm['delete'](object) syntax. I don't see it being an issue. 18.12.2013, 00:59, "Andrea Giammarchi" andrea.giammar...@gmail.com:sorry what ? https://github.com/WebReflection/es6-collections#es6-harmony-collections-fast-polyfillhttps://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.jshttps://github.com/Benvie/ES6-Harmony-Collections-Shimhttps://github.com/paulmillr/es6-shimhttps://gist.github.com/Gozala/1269991 regards On Tue, Dec 17, 2013 at 11:38 AM, Alex Kocharin a...@kocharin.ru wrote: ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, "Andrea Giammarchi" andrea.giammar...@gmail.com: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 ```_javascript_var wm = new WeakMap;wm.delete(Object);``` Simple minification does the right, resulting in an IE8 safe script such` wm['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 RegardsOn Tue, Dec 17, 2013 at 1:38 AM, David Bruant bruan...@gmail.com wrote:Le 17/12/2013 10:19, Shijun He a écrit :There are some methods using reserved word "delete", such as
Re: Could delete methods rename to remove?
On Wed, Dec 18, 2013 at 11:30 AM, Rick Waldron waldron.r...@gmail.comwrote: 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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
On Wed, Dec 18, 2013 at 11:28 AM, Alex Kocharin a...@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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.assign with several source objects
Rick I tend to aree with you if not that the second argument of
Object.create has basically reached zero libraries and popularity out there
due un-shimmable and boring to write common/usual properties.
In this very specific case it would be inconsistent with the previous
argument too since that won't be checked through getOwnPropertyNames in any
case ... you know what I mean?
Cheers
On Tue, Dec 17, 2013 at 7:06 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Tue, Dec 17, 2013 at 8:17 PM, Brendan Eich bren...@mozilla.com wrote:
It's now or never. I agree multiple sources are useful enough to do now;
I don't see a different third parameter that would be precluded by deciding
this. But others may disagree.
A third Properties argument that matches the second Properties argument to
Object.create() and Object.defineProperties
class Cycle {
constructor(details) {
Object.assign(this, details, {
wheels: {
value: details.type === tricycle ? 3 : 2,
configurable: false,
writable: false
}
});
}
}
var trike = new Cycle({
color: red,
type: tricycle
});
... Which doesn't break the reduce pattern since the index would
effectively be meaningless in that context, ie.
Object.getOwnPropertyNames(Object(1)).length === 0;
Anyway...I had originally pushed for Object.assign with multiple sources
and dropped it when consensus seemed to hinge on one target, one source.
The third Properties argument is compelling and doesn't prevent using
Object.assign as a primitive mechanism for library code to build on top of.
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
On Tue, Dec 17, 2013 at 10:45 PM, Shijun He hax@gmail.com wrote: On Wed, Dec 18, 2013 at 11:30 AM, Rick Waldron waldron.r...@gmail.comwrote: 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. Submit patches—libraries intended for use in IE8 should be made to support that platform, it's that simple. 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'. 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. Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could delete methods rename to remove?
On Tue, Dec 17, 2013 at 11:02 PM, Shijun He hax@gmail.com wrote: On Wed, Dec 18, 2013 at 11:28 AM, Alex Kocharin a...@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. I doubt it. https://github.com/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 ;) Rick ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
