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 <m...@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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
