> On Aug 22, 2014, at 11:07, Antti Koivisto <koivi...@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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
