It was suggested I bring this to webkit-dev. There was some recent work to move the many parameters passed to the Page constructor into a single PageClients structure. The current assumption is that if a feature is enabled (at runtime or compile time) then Page will always get a non-null client for that feature. This allows the Page constructor to have something like this: , m_deviceMotionController(RuntimeEnabledFeatures::deviceMotionEnabled() ? n ew DeviceMotionController(pageClients.deviceMotionClient) : 0) and DeviceMotionController's constructor has an ASSERT(m_client). The problem is that not every Page needs every client. SVGImage, for example, creates a Page without all clients. Some platform ports branch around this code. The current solution is to create EmptyClient implementations. https://bugs.webkit.org/show_bug.cgi?id=43848 https://bugs.webkit.org/show_bug.cgi?id=43533 Related discussion: https://lists.webkit.org/pipermail/webkit-dev/2010-July/013597.html Wouldn't it be easier to allow null clients than to have these EmptyClient implementations? Dean
On Mon, Aug 16, 2010 at 9:43 PM, Dean Jackson <dino@apple.com> wrote:
It was suggested I bring this to webkit-dev.
There was some recent work to move the many parameters passed to the Page constructor into a single PageClients structure. The current assumption is that if a feature is enabled (at runtime or compile time) then Page will always get a non-null client for that feature.
This allows the Page constructor to have something like this:
, m_deviceMotionController(RuntimeEnabledFeatures::deviceMotionEnabled() ? n ew DeviceMotionController(pageClients.deviceMotionClient) : 0)
and DeviceMotionController's constructor has an ASSERT(m_client).
The problem is that not every Page needs every client. SVGImage, for example, creates a Page without all clients. Some platform ports branch around this code. The current solution is to create EmptyClient implementations.
https://bugs.webkit.org/show_bug.cgi?id=43848 https://bugs.webkit.org/show_bug.cgi?id=43533
Related discussion: https://lists.webkit.org/pipermail/webkit-dev/2010-July/013597.html
Wouldn't it be easier to allow null clients than to have these EmptyClient implementations?
Dean
I think that'd be a lot of null checks. It seems like it could add a fair bit of code throughout WebCore, and folks would have to be careful not to forget any null checks. EmptyClients seems like a fairly isolated solution, which only requires maintenance when a client interface changes. -Darin
Wouldn't it be easier to allow null clients than to have these EmptyClient implementations?
Dean
I think that'd be a lot of null checks. It seems like it could add a fair bit of code throughout WebCore, and folks would have to be careful not to forget any null checks.
EmptyClients seems like a fairly isolated solution, which only requires maintenance when a client interface changes.
-Darin
I had't looked at this issue before and read the answer before the question but the current solution is what I thought would be a reasonable approach. In some cases you also need to have many different types of "null" or instrument your "null" and you have "debug null" etc. Aside from removing clutter, this moves any "overhead" to just the users of the (fast) null object. Usually the problem with zero is that there is only one of them :) You could probably even autogenerate null objects from headers to save maintenance.
On 16/08/2010, at 11:35 PM, Darin Fisher wrote:
Wouldn't it be easier to allow null clients than to have these EmptyClient implementations?
Dean
I think that'd be a lot of null checks. It seems like it could add a fair bit of code throughout WebCore, and folks would have to be careful not to forget any null checks.
Fair enough. I was just trying to avoid the branching before the Page is constructed, but you're right. (If I can move DeviceMotion to Document, it might not need anything on Page anyway) Dean
participants (3)
-
Darin Fisher
-
Dean Jackson
-
Mike Marchywka