As an external contributor, I found Supplementables and Supplements to be an extremely useful way of avoiding touching large headers that trigger a rebuild of large parts of Blink.
But more importantly, I think that such major decisions should be taken after a public discussion (where different folks can present their pro/con arguments) and not presented as "water under the bridge". It'd be good to aim for that next time. On Fri, Nov 28, 2025 at 9:23 AM Steinar H. Gunderson <[email protected]> wrote: > On Thu, Nov 27, 2025 at 04:42:58PM -0800, Daniel Cheng wrote: > > I think there's a balance to be struck here, and defaulting everything > to a > > member of LocalDOMWindow/Document/LocalFrame/Navigator doesn't really > seem > > like a maintainable approach, even if it's good for benchmarks. > > To be clear, I considered the change to increase maintainability and > readability; benchmarks was only a part of the equation. Size decrease was > a > nice bonus. > > These members were there all along. It's just that they are more visible > now > instead of being hidden away by compiler-generated code; I consider that a > good thing. We haven't created more layer violations -- if A is not allowed > to hold B, it shouldn't be allowed to do so through a Supplementable-like > system either IMO (and Supplementable had big warnings on it that it was > prone to type confusion if used with inheritance). > > To put it another way: If you came to the current Blink code base with no > knowledge of the past, would anyone say that we should take a lot of the > members on ExecutionContext and stick them into an untyped hash table? > (If so, should e.g. OriginTrialContext have been part of this table, > which it wasn't before?) A lot of stuff was stuck into ExecutionContext's > Supplementable without even being in different layers, and I'm not sure > what > distinguished them from the other Members that were there before. And I've > honestly never seen this pattern recommended anywhere else before; it > looked > odd to me all along, which is why I invested time in removing it. > > But as others have pointed out, it's water under the bridge. I guess it > _is_ > possible to revert it still if you wish, but it would be very > conflict-prone. > > /* Steinar */ > -- > Homepage: https://www.sesse.net/ > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/64st4nwknc2eq5vb7seb6ri5d6qb4l4nsqqpo7yvjhqhwmkepk%40hoayrxvm5v5k > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKBWxdMQhHJ4ugVsqsDar-4VfjSLKjvcsR8Zn1TJ_1bLQ%40mail.gmail.com.
