[webkit-dev] SharedWorkers alternate design

[Jeremy Orlow]

Note that Chromium uses the same binary/libraries for the render process and
the browser process, which means that the decision can't be made in compile
time for us.

There might be ways (like what you mentioned) to allow the compiler to skip
all the virtual stuff for implementations where the decision can be made in
compile time (the normal case).  I've got some ideas....I'll try to explain
them when I get a second later this afternoon.

J

On Tue, May 26, 2009 at 10:43 AM, Drew Wilson <atwilson at google.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/b5b5c2aa/attachment.html>