setTimeout(function() {if (this.hasThePower_) { // silently fails on wrong |this|this.startWarpDrive_(function(speed) {
assert(speed == this.TOP_SPEED_);
}.bind(this));
}}.bind(this)); // if .bind(this) is omitted, bad things happen
setTimeout(() => {if (this.hasThePower_)this.startWarpDrive_(s => assert(s == this.TOP_SPEED_));});
var people = [{name: 'Waldo'}, {name: 'Wenda'}];
// Found Waldo!people.find(p => p.name == 'Waldo').found = true;var missing = people.filter(p => !p.found).map(p => p.name);// ['Wenda'] is missing.
(a) => {return [];} // equal to: a => []
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
"Please, stop going off topic in this group. This is a development group, not a standards body, or anything else that is related to *proposing* platform ideas."Can we please apply the same rules to all equally in future?
--
+1Having written 1000s of lines of JS code recently (both ways), the arrow syntax is much cleaner, concise, and sane w.r.t. scoping rules; especially with our callback-heavy API style, and when using Promises. More readable code, less bugs...what's not to like? In fact, we should probably say something to the effect of "prefer using the arrow syntax for anonymous functions."
2016/12/14 午前8:23 "Devlin Cronin" <rdevlin...@chromium.org>:+1; arrow functions will help a lot. Your suggestions re when to use () and {} sound good. As PhistucK mentioned, there might be some issues on iOS, so there arises the question of whether or not we're okay with saying "We can use these everywhere except here."One other concern: I know that in the past the v8 team has mentioned certain ES6 features are slower than their <=ES5 counterparts; have we asked which features those are (if that's still the case for any - maybe they've all been fixed), and documented somewhere that we should avoid using those in extremely performance-sensitive code? (Hopefully with bugs that can be fixed and then places updated?) I imagine the number of places that this will be important in chromeJS is relatively small, but probably >0.
On Wed, Dec 14, 2016 at 11:37 AM, Yuri Wiitala <m...@chromium.org> wrote:+1Having written 1000s of lines of JS code recently (both ways), the arrow syntax is much cleaner, concise, and sane w.r.t. scoping rules; especially with our callback-heavy API style, and when using Promises. More readable code, less bugs...what's not to like? In fact, we should probably say something to the effect of "prefer using the arrow syntax for anonymous functions."The Google ES6 style guide did this and it was a little too highly encouraged, IMO (people started saying "function is banned!"). We can make the wording stronger over time if we'd like. Right now I think they can co-exist with a clear explanation of why => is better in the style guide.2016/12/14 午前8:23 "Devlin Cronin" <rdevlin...@chromium.org>:+1; arrow functions will help a lot. Your suggestions re when to use () and {} sound good. As PhistucK mentioned, there might be some issues on iOS, so there arises the question of whether or not we're okay with saying "We can use these everywhere except here."One other concern: I know that in the past the v8 team has mentioned certain ES6 features are slower than their <=ES5 counterparts; have we asked which features those are (if that's still the case for any - maybe they've all been fixed), and documented somewhere that we should avoid using those in extremely performance-sensitive code? (Hopefully with bugs that can be fixed and then places updated?) I imagine the number of places that this will be important in chromeJS is relatively small, but probably >0.Like I mentioned earlier in Performance, I believe => to be fast already. [+adamk@, bmeurer@, mstarzinger@]
--
I haven't heard any substantial objections, so I'm going to move => to the Allowed Features list in the style guide.I'm also thinking about doing some [semi-]automated refactoring to move .bind(this) to use =>. I started prototyping here.I've noted caveats of => in the ES6 style guide, but I'll also add them here.
- (permanent) => does not work on iOS9
I've added a presubmit that looks for => in code I believe to be potentially run on iOS9. (currently: ios/, ui/webui/resources, and components/).
Can you be a bit more detailed
☆PhistucK
(and did you file a bug?)? :)