| 00:27 | <devsnek> | I think for future large changes like class fields it would be nice to split them into multiple commits |
| 00:44 | <bakkot> | it's certainly nicer that way, but it's often a great deal of work |
| 00:45 | <bakkot> | I'd be open to doing it if it's something many people would get a lot of benefit from |
| 00:47 | <devsnek> | i can't speak for anyone else but i would certainly benefit from it |
| 01:18 | <littledan> | We did a bunch of work to maintain them separately for a while across rebases but it was ultimately merged |
| 01:19 | <littledan> | It would help to know why anyone would benefit |
| 01:19 | <littledan> | Engines did not end up slicing up shipping based on the proposal split |
| 01:20 | <devsnek> | oh i don't mean by the individual field types |
| 01:20 | <littledan> | The state of the language with the different subsets is well-documented; it wasn't clear to me what multiple commits would give us |
| 01:20 | <devsnek> | i mean like, there is a lot of refactoring across various things that happened to enable "class fields" in the general sense |
| 01:21 | <littledan> | OK, well, it sounds like you're asking for an even more involved factoring then |
| 01:21 | <devsnek> | going over thousands of lines of diff to understand what changed is a very difficult way to figure it out |
| 01:21 | <littledan> | I dunno, I am happy to answer questions |
| 01:22 | <littledan> | But basically no existing semantics changed, only new things were added |
| 01:25 | <ljharb> | i'm hearing gus' request as, smaller git commits so that one can choose to look at smaller chunks of conceptual additions at a time. which is definitely a difficult ask (but a nice to have), and on class fields in particular would have likely been exceedingly difficult since it was the combining of three repos |
| 01:26 | <devsnek> | yeah for example, moving classes from methods to fields, without adding all the new field kinds, might have been one step, idk |
| 01:26 | <devsnek> | i don't think it matters too much, the past is the past |
| 01:37 | <bakkot> | yeah, to be clear, it would definitely be an after-all-other-work-is-done refactoring |
| 01:38 | <bakkot> | which is pretty common for this type of thing, it's just a bunch of work |
| 01:39 | <ljharb> | in my experience it actually makes it much easier if you start out keeping commits separate, and keep followup changes split into separate commits that point to the ones they should be squashed into later - but it's definitely not a natural way of working with git for many |
| 01:42 | <devsnek> | git rerere can help a lot with allowing more commits |
| 01:42 | <devsnek> | for annoying rebases |
| 01:47 | <bakkot> | ljharb: if you do the work in a way where that works, yeah |
| 01:47 | <bakkot> | often there's a big refactor that happens across code touched by many commits, so often you kind of need to come up with the story you're going to tell once you have everything created |
| 01:47 | <bakkot> | which is probably what I would have done for class fields |
| 01:47 | <ljharb> | very fair point |
| 03:24 | <littledan> | If someone wants to contribute this history refactoring, we can probably find time in Igalia to review it, but we don't plan to spend time writing it ourselves. |
| 03:25 | <ljharb> | we wouldn't change the commits that have landed - it's more something to think about for future large PRs, i think |
| 03:32 | <bakkot> | yeah |
| 03:32 | <bakkot> | also probably would be something the editors would take on |
| 03:35 | <devsnek> | yes i don't think we should rewrite the history |
| 03:35 | <devsnek> | i was just saying it should be something to think about in the future |
| 19:07 | <devsnek> | has anyone ever proposed filter map |
| 23:30 | <ljharb> | wouldn't that be .flatMap((...args) => predicate(...args) ? [mapper(...args)] : [])? |