Food for thought if folks are going to design Supplementable V2. base::SupportsUserData has some problems: * construction is usually lazy, which results in non-deterministic construction/destruction ordering * no enforcement mechanism for dependency acquisition. easy to create dependency cycles.
We've taken a different approach with //chrome/browser. See: * chrome/browser/ui/browser_window/public/browser_window_interface.h * ui/base/unowned_user_data/unowned_user_data_host.h * chrome/browser/ui/browser_window/public/browser_window_features.h * chrome/browser/ui/browser_window/internal/browser_window_features.cc The basic premise is that we have explicit construction/destruction ordering with dependency acquisition in BrowserWindowFeatures. These features can register themselves with BrowserWindowInterface::GetUnownedUserDataHost. Clients of BrowserWindowInterface can obtain a specific feature by including the header for the feature and then fetching from BrowserWindowInterface::GetUnownedUserDataHost. The migration isn't finished but all the major pieces are there if folks want to poke around. This feature was in turn inspired by UnownedUserDataHost <https://source.chromium.org/chromium/chromium/src/+/main:base/android/java/src/org/chromium/base/UnownedUserDataHost.java;l=26> from chrome on android. On Monday, December 1, 2025 at 8:58:27 AM UTC-8 Steve Kobes wrote: > On Fri, Nov 28, 2025 at 4:20 AM Daniel Cheng <[email protected]> wrote: > >> >> >> >>> >>> 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). >>> >> >> Though `Supplementable` and `base::SupportsUserData` have sharp edges and >> could use improvement, the underlying abstraction still has value. >> > > Perhaps this is a good opportunity to design a Supplementable V2 that > polishes the rough edges? > -- 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/dc7ace4e-e0b8-4520-9bf1-0fab4436145cn%40chromium.org.
