[webkit-dev] SharedWorkers alternate design

[Drew Wilson]

Thanks for the explanation, Maciej. I actually looked at ResourceRequest
prior to sending my mail, but I wasn't clear what makefile magic was being
used to load the correct version of ResourceRequest.h for a given platform.

For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see only
two references to ResourceRequest.h: platform/network/curl and
platform/network/cf, but clearly we might want to use the chromium/ or win/
versions as well. Can someone give me a quick explanation of how the
platform-specific version is selected at compile time?

Do we have a naming convention for the "default" implementation? I'm
expecting there to be two versions of SharedWorkerRepository - the chromium
version, and the <everything else> version.

-atw

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/286ea14b/attachment.html>