Supplement should have a Member to the corresponding Supplementable object (Part 1)

third_party/WebKit/Source/platform/Supplementable.h

 /*
  * Copyright (C) 2012 Google, Inc. All Rights Reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 75 matching lines @@
 //
 // Note that reattachThread() does nothing if assertion is not enabled.
 //
 
 template<typename T>
 class Supplementable;
 
 template<typename T>
 class Supplement : public GarbageCollectedMixin {
 public:
+    // TODO(haraken): Remove the default constructor.
+    // All Supplement objects should be instantiated with m_host.
+    Supplement() { }
+    explicit Supplement(T& host) : m_host(&host) { }
+    T* host() const { return m_host; }
+
     static void provideTo(Supplementable<T>& host, const char* key, Supplement<T>* supplement)
     {
         host.provideSupplement(key, supplement);
     }
 
     static Supplement<T>* from(Supplementable<T>& host, const char* key)
     {
         return host.requireSupplement(key);
     }
 
     static Supplement<T>* from(Supplementable<T>* host, const char* key)
     {
         return host ? host->requireSupplement(key) : 0;
     }
 
-    DEFINE_INLINE_VIRTUAL_TRACE() { }
+    DEFINE_INLINE_VIRTUAL_TRACE()
+    {
+        visitor->trace(m_host);
+    }
+
+private:
+    WeakMember<T> m_host;

[sof, 2016/07/13 07:20:41]

Thinking about this some more, what value does it bring over status quo to have
a WeakMember<> here? i.e., could you clarify how you intend to make use of
|m_host| in supplement impls?

[haraken, 2016/07/13 07:24:26]

Many Supplement classes that inherit from DOMWindowProperty and
LocalFrameLifecycleObserver are inheriting from them just because they want to
get the host object. If Supplement provides the host object, we can remove the
inheritance.

It's nasty that we need to make many NavigatorXXX objects inherit from
DOMWindowProperty/LocalFrameLifecycleObserver. They should be able to just get
the host object from Supplement.

[sof, 2016/07/13 07:39:41]

ok, thanks for clarifying the purpose, i.e., |m_host| is not a lifetime-extender
for supplement, but a way to avoid keeping ad-hoc "parent pointers".

[haraken, 2016/07/13 07:42:12]

Yes, right.

 };
 
 // Supplementable<T> inherits from GarbageCollectedMixin virtually
 // to allow ExecutionContext to derive from two GC mixin classes.
 template<typename T>
 class Supplementable : public virtual GarbageCollectedMixin {
     WTF_MAKE_NONCOPYABLE(Supplementable);
 public:
     void provideSupplement(const char* key, Supplement<T>* supplement)
     {
@@ skipping 49 matching lines @@
 };
 
 template<typename T>
 struct ThreadingTrait<Supplementable<T>> {
     static const ThreadAffinity Affinity = ThreadingTrait<T>::Affinity;
 };
 
 } // namespace blink
 
 #endif // Supplementable_h