| 01:59 | <snek> | anyone gonna be at gamescom? |
| 18:20 | <littledan> | Orama is allowed to attend the TC39 plenary next week, right? |
| 20:21 | <Michael Ficarra> | littledan: (RE Array.prototype.group) I think the answer to "how do we choose web-compatible Array.prototype method names?" is obvious but we just don't want to accept it: stop trying to choose good names |
| 20:22 | <littledan> | Michael Ficarra: There's something in common with the group name as the previous global name: people searched for the name and found too many results, so it was too much to look through, and they sort of assumed it was compatible (but without reporting all of that logic to the committee in advance). In the future, if a search yields that sort of result, I think the next step is to choose something else. |
| 20:22 | <littledan> | so, I agree |
| 20:22 | <Michael Ficarra> | bad/verbose names are much less risky, but we want the name to be good, so we take the risks anyway |
| 20:23 | <littledan> | I think for Array methods in particular, we should just use things that we can demonstrate to be pretty unique |
| 20:23 | <littledan> | Array methods have been found to be uniquely risky unlike anything else |
| 20:23 | <Michael Ficarra> | yes, we need an especially high bar for Array prototype method names |
| 20:24 | <Michael Ficarra> | evidence of compatibility, not just lack of evidence of incompatibility |
| 20:24 | <littledan> | well, I'd like that if someone could provide it, but I'm not sure what such evidence would look like |
| 20:25 | <littledan> | what advice would you give to a new delegate who wants to take on the Array grouping project? |
| 20:25 | <Michael Ficarra> | a new delegate? "don't" |
| 20:26 | <littledan> | OK, then, an experienced delegate--what would you tell them to do? |
| 20:26 | <Michael Ficarra> | "hi I'm new here, let me try to solve this override mistake for y'all" |
| 20:27 | <Michael Ficarra> | if code search can show a name is effectively nonexistent on the web, that would be good evidence |
| 20:27 | <Michael Ficarra> | that would probably necessitate a pretty terrible name choice though |
| 20:27 | <littledan> | previously people tried GitHub code search and found results which initially appeared to be stronger support than what was ultimately shown |
| 20:28 | <littledan> | Let's try to give actionable advice to champions here (or declare bankruptcy on Array methods and just not do them) |
| 20:28 | <Michael Ficarra> | if they wanted to straddle the middle, they would have to do something like collect/analyse usage info in a large-ish browser |
| 20:29 | <Michael Ficarra> | yeah, GitHub code search should not be considered sufficient, most code is not OSS |
| 20:29 | <littledan> | people always say "analyze usage in a browser" but that doesn't really seem to be available in practice |
| 20:29 | <littledan> | I dunno if it ended up playing a role in global with some kind of work with Edge, but I haven't heard of it being used since |
| 20:30 | <littledan> | this is more awkward than adding other kinds of telemetry/usecounters since it's a property that doesn't exist |
| 20:32 | <Michael Ficarra> | may be awkward, but I don't see why it couldn't be done (by someone with the authority to ship in said browsers) |
| 20:32 | <littledan> | I just don't know how to do it (and I've contributed code which shipped in browsers after stopping working directly for one) |
| 20:33 | <littledan> | maybe you see a way to do it that I don't? |
| 20:34 | <littledan> | like, it'd be too slow to replace Array.prototype with a Proxy or something |
| 20:36 | <Michael Ficarra> | I was thinking a magic property like document.all which appeared not there but reported a use counter when assigned/defined |
| 20:36 | <Michael Ficarra> | I'm not talking about an existing facility here |
| 20:37 | <Michael Ficarra> | Array.prototype.length is already magical |
| 20:37 | <littledan> | I think property access on Array.prototype has to be faster than property access on document. And the magic of length is baked into a lot of places and difficult to replicate. |
| 20:38 | <littledan> | Anyway, if we want to call a pause on Array methods until someone puts in the work to do this very strong dynamic analysis, that's a conclusion we could come to, we should just expect this to take a long time. |
| 20:40 | <Michael Ficarra> | I'm personally okay with either approach: raise the bar so we can confidently ship come stage 3, or move to stage 3 with an unknown name, accepting that we may need to unship and retry with a new name an unbounded number of times before moving to stage 4 |
| 20:40 | <Michael Ficarra> | browser implementors may have a different opinion though |
| 20:41 | <littledan> | yeah it'd be nice if we could find some strategy where the champion can be the one doing the work, rather than just implementers. Maybe some kind of search in HTTPArchive? |
| 20:49 | <shu> |
most definitely not scalable |
| 20:50 | <shu> |
the "awkwardness" you refer to is really "unacceptably slow and cannot be shipped" |
| 20:50 | <shu> | it's not "impossible" |
| 20:50 | <shu> | well, it's in practice impossible |
| 20:51 | <shu> | but not impossible in the sense that like, we don't know how to code it |
| 20:52 | <shu> | a difference between JS engines and this kind of telemetry on other web APIs defined in WebIDL is the performance pressures are probably an order-of-magnitude different |
| 20:52 | <shu> | if you could get google and apple and mozilla to stop competing on performance at all then we can talk! |
| 20:54 | <shu> | oh and microsoft |
| 20:55 | <littledan> | to be clear: we want you to keep competing on performance |
| 20:58 | <shu> | yes sorry this is all a bit tongue in cheek. i don't think the current state of things is wrong: the optimal state of a widely used and supported language most likely should not be optimized for ease of changing |
| 21:38 | <TabAtkins> | well, I'd like that if someone could provide it, but I'm not sure what such evidence would look like |
| 21:38 | <TabAtkins> | If it's super low, great. If not, we can dig into exactly what the usage is and see if it's innocent or not, but that does require more manual labor. |
| 21:39 | <shu> | what does a use counter look like for assessing compatibility of a new Array.prototype method? |
| 21:39 | <TabAtkins> | At least, I presume Use Counters are plumbed into the JS engine enough to be usable. |
| 21:39 | <shu> | i've added use counters mainly to assess the compatibility of removing things |
| 21:40 | <shu> | we have plenty of use counters, but they aren't free and some things are much easier to track than others |
| 21:40 | <littledan> | Use Counters are definitely plumbed through V8, I just don't know how to efficiently add a counter for this sort of thing |
| 21:40 | <TabAtkins> | Whatever c++ gets invoked for expandos, the use counter would monitor, I presume. |
| 21:40 | <TabAtkins> | yeah they're not free, but we still have a bajillion of them bc they're useful |
| 21:40 | <shu> | alas it is not C++ but like, 10 different places across C++ and generated code (handwritten assembly) |
| 21:40 | <shu> | i guarantee you adding a check to Array.prototype object lookups will regress speedometer |
| 21:40 | <shu> | and we will back it out |
| 21:41 | <TabAtkins> | lol, well a telemetry run on nightly might be enough |
| 21:41 | <TabAtkins> | at least to give initial results, which probably would have shown the .group usage was high |
| 21:43 | <shu> | i think our performance mental models significantly differ |
| 21:43 | <shu> | mainly because you said expandos |
| 21:47 | <TabAtkins> | lol |
| 21:49 | <TabAtkins> | An attempt to get a given property name from the Array.prototype object. |