Thanks for the explanation, Maciej. I actually looked at ResourceRequest prior to sending my mail, but I wasn&#39;t clear what makefile magic was being used to load the correct version of ResourceRequest.h for a given platform.<br>
<br>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?<br>
<br>Do we have a naming convention for the &quot;default&quot; implementation? I&#39;m expecting there to be two versions of SharedWorkerRepository - the chromium version, and the &lt;everything else&gt; version.<br><br>-atw<br>
<br><div class="gmail_quote">On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On May 26, 2009, at 10:21 AM, Darin Adler wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On May 26, 2009, at 10:16 AM, Drew Wilson wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
OK, I&#39;ve got two strong votes for the interface + static factory approach. Any objections from the rest of the WebKit team? If I don&#39;t hear any counter proposals, I&#39;ll do that.<br>
</blockquote>
<br>
I think it&#39;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&#39;t.<br>

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

</blockquote>
<br></div></div>
I agree with Darin&#39;s comments here. We&#39;ve tried hard to avoid using runtime polymorphism for compile-time choices. Here it&#39;s probably not performance-critical, but it can be avoided.<br>
<br>
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.<br>

<br>
The basic idea is this. Let&#39;s say you have a class FooBar.<br>
<br>
- 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.<br>

- Each port subclasses FooBarBase to define FooBar, adding constructors, platform-specific data members, and any needed platform-specific private helpers or type conversions.<br>
- 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.<br>
- Cross-platform code using the class just uses FooBar. The Base class is an implementation detail.<br>
<br>
(Darin F., please correct me if I have not done justice to this technique.)<br>
<br>
Note that this method has no runtime cost - there&#39;s no need to use virtual methods or other forms of runtime indirection. And there&#39;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&#39;s a little subtle at first but I think it results in nice, understandable code.<br>

<br>
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.<br>
<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div><br>