I agree that this approach is powerful.  However there are (not too frequent) situations when a port like Chromium wants to use both the WebKit implementation and its own implementation, switching in runtime.  For workers, this happened with WorkerContextProxy/WorkerObjectProxy which are the interfaces that a worker object implements/uses.  Since workers run in a separate process from the renderer, we use our own implementations of these interfaces that know about IPC etc.  However once we&#39;re in the worker process, we want to run nested workers in the same process, in which case we want to use the WebKit implementation of these interfaces directly without using Chromium&#39;s.<div>
<br></div><div>Chromium doesn&#39;t have this use case for SharedWorkerRepository, so it doesn&#39;t need to be an interface if that&#39;s more consistent with WebKit code.  Apology for the wrong suggestion Drew :)<br><div>
<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="margin:0 0 0 .8ex;border-left:1px #ccc solid;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="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On May 26, 2009, at 10:16 AM, Drew Wilson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org" target="_blank">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>
</div></div></blockquote></div><br></div></div>