[Webkit-unassigned] [Bug 197973] 'analysis-task-configurator-pane' does not update when switch from one analysis task to another

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=197973

--- Comment #24 from Ryosuke Niwa <rniwa at webkit.org> ---
(In reply to Alexey Proskuryakov from comment #23)
> It looks like the discussion got sidetracked, as the main issue appears to
> be how tests are written. Is the discussion in the bug still the latest on
> this topic, or was there an offline discussion already?

Not yet. Yes, we should probably focus on addressing that.

> This is very different from '==' vs. '==='. The fact that const correctness
> is broken in C++ is pretty well known (at least now, maybe not as well known
> when Node const correctness was attempted). The choice of equality operator
> in JS is something where your position is uncommon, if not unique. There are
> things about '==' that make reasoning about it harder, and more dependent on
> overall understanding of the code.
> 
> This particular choice should be discussed on webkit-dev in addition to this
> bug, but the WebKit approach has always been to give people who hack on the
> code today a stronger say on such matters. Typically,
> managers/architects/experts only get a chance to convince, not to force.

I think I tend to agree that I would have used === operator if I wrote perf dashboard code from scratch today. When I initially wrote v3 UI code, === operator was significantly slower than == operator in JSC due to historical reasons. Because I primarily wrote v3 UI code in order to speed up the UI, I opted to mostly use ==.

The problem with start deploying === everywhere is precisely the semantics difference they have with ==. I think we had at least one or two bugs caused by the perf dashboard relying on semantics of == which treats strings and numbers equal whereas Map or Set don't treat them equal in their keys. So in a way, deploying === in the perf dashboard code right now is anything but a major regression risk.

I'm more than open to the discussion of eventually moving to === in the perf dashboard code to be consistent with Web Inspector especially if we end up more contributors who contribute to both but right now, I really don't see an obvious benefit of deploying right away, let alone by someone who had never worked on the perf dashboard code before.

On the contrary, we're very aggressively replacing `var` with `let` and `const` because they can be deployed in each function / block separately, and there is virtually no way of random code elsewhere in the codebase depending on `var` being used in some function. Similarly, we've been deploying class syntax, async, & await because they radically improve the readability of the code by eliminating boilerplates and allowing more natural flow of the code.

So yes, I know the various benefits === provides (and that most JS developers prefer it over ==) but I really don't see much benefit in deploying them in the perf dashboard code today. If anything, there is a serious risk of regression because we literally had them by deploying new data structures that rely on the semantics of ===.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190626/74f0d9ca/attachment-0001.html>