Steve Kobes <[email protected]> writes: > 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?
If this gets re-added (and maybe even re-designed), I suggest that we refrain from using this mechansim in cases where having a regular member is reasonable, i.e. if that wouldn't cause any layer violations. We should not use Supplementable as an attempt to hide the fact that some classes have many associations and are a central part of some machinery, and end up with a lot of members. Better redesign that class / machinery instead if it's a problem, or let such classes remain big, and honest about it. Abusing Supplementable in such cases just makes the code harder to navigate (and slightly bigger and slower). -- Morten Stenshorne, Software developer, Blink/Layout, Google, Oslo, Norway -- 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/ozzijyz5b6ix.fsf%40nusse.osl.corp.google.com.
