[webkit-dev] SharedWorkers alternate design

[Maciej Stachowiak]

On May 26, 2009, at 10:43 AM, Drew Wilson 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?

This is apparently done via include paths in the various project files.

> 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.

With the Base pattern, it's not necessary to give the port-specific  
subclasses special names. But if a name becomes necessary I'd say  
"generic" or "default" or something like that.

Regards,
Maciej


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