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.<br><br>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&#39;ve got some ideas....I&#39;ll try to explain them when I get a second later this afternoon.<br>
<br>J<br><br><div class="gmail_quote">On Tue, May 26, 2009 at 10:43 AM, Drew Wilson <span dir="ltr">&lt;<a href="mailto:atwilson@google.com">atwilson@google.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;">
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<div><div></div><div class="h5"><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" target="_blank">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><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>
</div></div><br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div><br>