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'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's.<div>
<br></div><div>Chromium doesn't have this use case for SharedWorkerRepository, so it doesn't need to be an interface if that'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"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></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'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.<br>
</blockquote>
<br>
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.<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'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.<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'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'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.<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>