Make DisplayItemClient an interface

third_party/WebKit/Source/platform/graphics/paint/DisplayItemClient.h

Index: third_party/WebKit/Source/platform/graphics/paint/DisplayItemClient.h
diff --git a/third_party/WebKit/Source/platform/graphics/paint/DisplayItemClient.h b/third_party/WebKit/Source/platform/graphics/paint/DisplayItemClient.h
index 32f312e8ba20c5410b5a3e2efe935bf693a279e1..b869287e01b93c8b93c7568e82516a305c4f52fa 100644
--- a/third_party/WebKit/Source/platform/graphics/paint/DisplayItemClient.h
+++ b/third_party/WebKit/Source/platform/graphics/paint/DisplayItemClient.h
@@ -6,52 +6,20 @@
 #define DisplayItemClient_h
 
 #include "platform/PlatformExport.h"
-#include "platform/heap/Heap.h"
 #include "wtf/text/WTFString.h"
 
 namespace blink {
 
-class DisplayItemClientInternalVoid;
-using DisplayItemClient = const DisplayItemClientInternalVoid*;
-
-inline DisplayItemClient toDisplayItemClient(const void* object) { return static_cast<DisplayItemClient>(object); }
-
-// Used to pass DisplayItemClient and debugName() (called only when needed) from
-// core/layout module etc. to platform/paint module.
-// The instance must not out-live the object. Long-time reference to a client must
-// use DisplayItemClient.
-class PLATFORM_EXPORT DisplayItemClientWrapper final {
-    DISALLOW_NEW(); // Allow allocated in stack or in another object only.
+class PLATFORM_EXPORT DisplayItemClient {

[pdr., 2015/12/05 21:39:19]

Lets add a comment about what this class is for.

This is sort of a general thought (trchen or jbroman?) but if we named this
something more general, we could re-use this object as the base class for things
that can have paint properties too.

[Xianzhu, 2015/12/07 17:14:01]

Added an one-line comment.

I think we can address it later when we need to share it for other usages.

 public:
-    template <typename T>
-    DisplayItemClientWrapper(const T& object)
-        : m_displayItemClient(object.displayItemClient())
-        , m_object(reinterpret_cast<const GenericClass&>(object))
-        , m_debugNameInvoker(&invokeDebugName<T>)
-    { }
-
-    DisplayItemClientWrapper(const DisplayItemClientWrapper& other)
-        : m_displayItemClient(other.m_displayItemClient)
-        , m_object(other.m_object)
-        , m_debugNameInvoker(other.m_debugNameInvoker)
-    { }
-
-    DisplayItemClient displayItemClient() const { return m_displayItemClient; }
-    String debugName() const { return m_debugNameInvoker(m_object); }
-
-private:
-    DisplayItemClientWrapper& operator=(const DisplayItemClientWrapper&) = delete;
-
-    class GenericClass;
-    template <typename T>
-    static String invokeDebugName(const GenericClass& object) { return reinterpret_cast<const T&>(object).debugName(); }
-
-    DisplayItemClient m_displayItemClient;
-    const GenericClass& m_object;
-    using DebugNameInvoker = String(*)(const GenericClass&);
-    DebugNameInvoker m_debugNameInvoker;
+    virtual ~DisplayItemClient() { }
+
+    virtual String debugName() const = 0;

[pdr., 2015/12/05 21:39:19]

I think we have a potential diamond inheritance issue on LayoutObject. I'm
surprised the compiler doesn't complain.

class LayoutObject : public ImageResourceClient, public DisplayItemClient
class ImageResourceClient : public ResourceClient

Both have a debugName:
virtual String ResourceClient::debugName const
and
virtual String DisplayItemClient::debugName const

[Xianzhu, 2015/12/07 17:14:01]

It seems that the compilers allow multiple inherited interfaces to all have a
method with the same signature. In a LayoutObject the entries in the vtables for
the interfaces point to the same implementation method. This is different from
the case that a class inherits one super class through multiple paths.

 };
 
+inline bool operator==(const DisplayItemClient& client1, const DisplayItemClient& client2) { return &client1 == &client2; }
+inline bool operator!=(const DisplayItemClient& client1, const DisplayItemClient& client2) { return &client1 != &client2; }
+
 }
 
 #endif // DisplayItemClient_h