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.

Reply via email to