[webkit-dev] Please avoid inheriting concrete types over WebCore/WebKit boundary

Tim Horton timothy_horton at apple.com
Fri Aug 22 11:12:56 PDT 2014

> On Aug 22, 2014, at 11:07, Antti Koivisto <koivisto at iki.fi> wrote:
> Hi,
> 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.
> 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:
> class WebResourceLoadScheduler : public WebCore::ResourceLoadScheduler {
> class GraphicsLayerCARemote final : public WebCore::GraphicsLayerCA {
> etc.
> I don'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). 
> I think we should avoid this pattern in new code and possibly refactor some of the existing examples.

Agreed, I think as the remote layer tree project went on we realized that this (all of the WebKit2-side *Remote subclasses) was a huge mistake, and just haven’t fixed it yet (not sure how straightforward it will be to fix, either, but we should try).

>    antti
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

More information about the webkit-dev mailing list