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