<div dir="ltr">Hi,<div><br></div><div>To make callbacks from WebCore to WebKit(2) we have generally used approach where WebCore exports an abstract client interface which is then implemented on the WebKit side.</div><div><br>
</div><div>More recently there has been some proliferation of a pattern where we inherit directly from a concrete WebCore type and specialize it on the WebKit side, in some cases with a completely different implementation:</div>
<div><br></div><div>class WebResourceLoadScheduler : public WebCore::ResourceLoadScheduler {</div><div>class GraphicsLayerCARemote final : public WebCore::GraphicsLayerCA {<br></div><div>etc.</div><div><br></div><div>I don&#39;t think this is a good pattern. It makes understanding the code harder as you can no longer reason about it within the WebCore only (the WebCore side implementation you are looking at may be effectively dead code). It also blurs the library boundary (which is still useful at least as long as we support both WebKit and WebKit2). </div>
<div><br></div><div>I think we should avoid this pattern in new code and possibly refactor some of the existing examples.</div><div><br></div><div><br></div><div>   antti</div><div><br></div></div>