[webkit-dev] SharedWorkers alternate design

[John Abd-El-Malek]

I agree that this approach is powerful.  However there are (not too
frequent) situations when a port like Chromium wants to use both the WebKit
implementation and its own implementation, switching in runtime.  For
workers, this happened with WorkerContextProxy/WorkerObjectProxy which are
the interfaces that a worker object implements/uses.  Since workers run in a
separate process from the renderer, we use our own implementations of these
interfaces that know about IPC etc.  However once we're in the worker
process, we want to run nested workers in the same process, in which case we
want to use the WebKit implementation of these interfaces directly without
using Chromium's.
Chromium doesn't have this use case for SharedWorkerRepository, so it
doesn't need to be an interface if that's more consistent with WebKit code.
 Apology for the wrong suggestion Drew :)

On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On May 26, 2009, at 10:21 AM, Darin Adler wrote:
>
>  On May 26, 2009, at 10:16 AM, Drew Wilson wrote:
>>
>>  OK, I've got two strong votes for the interface + static factory
>>> approach. Any objections from the rest of the WebKit team? If I don't hear
>>> any counter proposals, I'll do that.
>>>
>>
>> I think it's unpleasant to pay run-time cost for a compile-time choice.
>> Sure, sometimes the extra cost is no big deal, but sometimes it can be a big
>> deal and I see no reason to choose idioms that use virtual functions if
>> there are equally good or better ones that don't.
>>
>> Are there really no better techniques than abstract base classes and
>> virtual functions for this sort of compile-time switch? How about the
>> technique used for ResourceRequest and ResourceResponse? Maybe Darin Fisher
>> can explain that one.
>>
>
> I agree with Darin's comments here. We've tried hard to avoid using runtime
> polymorphism for compile-time choices. Here it's probably not
> performance-critical, but it can be avoided.
>
> The ResourceRequestBase / ResourceRequest model (due to Darin Fisher) seems
> pretty clean to me. I would like to see more of our classes with
> port-specific implementation details move to this style. I think it could
> work for SharedWorkerRepository.
>
> The basic idea is this. Let's say you have a class FooBar.
>
> - You define a FooBarBase class that has the cross-platform interface and
> data members. But not all the methods are actually implemented in the
> cross-platform code. All of its constructors are protected so the class
> cannot be instantiated directly.
> - Each port subclasses FooBarBase to define FooBar, adding constructors,
> platform-specific data members, and any needed platform-specific private
> helpers or type conversions.
> - Each port implements the methods of FooBarBase that are
> platform-specific, freely downcasting to FooBar when needed since we have
> guaranteed that every instance of FooBarBase is actually a FooBar.
> - Cross-platform code using the class just uses FooBar. The Base class is
> an implementation detail.
>
> (Darin F., please correct me if I have not done justice to this technique.)
>
> Note that this method has no runtime cost - there's no need to use virtual
> methods or other forms of runtime indirection. And there's no need to #ifdef
> any headers, everything is controlled purely by including the right platform
> specific FooBar.h so it can be handled by include paths. It's a little
> subtle at first but I think it results in nice, understandable code.
>
> I think we should document this technique as the preferred way to make
> classes with port-specific implementation details and convert more of
> WebCore/platform/ to this technique, as well as using it for new classes.
>
> Regards,
> Maciej
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/c1755ae4/attachment.html>