| 17:21 | <ljharb> | bakkot: i wonder if it might be web compatible to remove the add/set calling in the Set/Map constructors, considering that anyone trying to override those in their subclass would throw (class X extends Set { #x = []; add(v) { this.#x.push(v); } } new X(['a']) throws, eg) |
| 17:26 | <Ashley Claymore> | I should of added unit tests to the deck https://docs.google.com/presentation/d/1-Hp4Qd0mmdufYCwI9fTdCxgt4xEHqE1mPfqRxzuzMvc/edit#slide=id.g10d8b1925be_0_0 |
| 17:28 | <bakkot> | ljharb: possibly; michael and I looked into it and even people who are subclassing Map usually also override the ctor |
| 17:29 | <ljharb> | seems like it'd be a win for normal collection usage as well as potential future methods/subclassing |
| 17:29 | <bakkot> | and it's not just private fields; even in plain es6 style, if your add method depends on fields added by the constructor it's not going to work |
| 17:29 | <bakkot> | no idea why we thought this was a good idea |
| 17:38 | <Ashley Claymore> | https://twitter.com/basarat/status/557680386042765312 |
| 17:42 | <Ashley Claymore> | I upset shu when I found out about this https://twitter.com/_shu/status/1362579124246646784 😅 |
| 18:43 | <bakkot> |
just to back that up, here's
and conversely, here's various bits of code which are _currently_ broken because of this behavior
and here's some which have explicitly had to work around it:
|
| 18:43 | <bakkot> | that said, this doesn't mean it would necessarily be web-compat to change the behavior at this point, since you can make something which depends on it (e.g. a Set subclass which just filters out a particular kind of value) |
| 18:56 | <Michael Ficarra> | btw we looked through examples of subclassing Set/Map for probably like 3 hours and I don't think we found a single example where the default constructor behaviour was useful |
| 19:09 | <bakkot> | the first two links above are places it would have been useful, they just didn't know it existed so they re-implemented it |