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
