The relevant Blink objects are garbage-collected (the Supplementable may not be the unique owner, and in any case ownership doesn't define the order in which objects are finalized once unreferenced), so we don't have a defined finalization order in most cases, regardless.
On Mon, Dec 1, 2025 at 9:08 PM Erik Chen <[email protected]> wrote: > 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/CACuR13e3hB_OGcddO62SYanbLrnMQT%2BA4%3DOKh%2By6pgQpbNJA5w%40mail.gmail.com.
