On Thu, Aug 20, 2009 at 6:17 PM, Drew Wilson <atwil...@chromium.org> wrote:
> I have to admit I'm somewhat fuzzy on the motivation behind our webkit API,
> although I gather the plan is to eventually upstream it to WebKit, and use
> it as our abstraction layer instead of using the (more mutable) WebCore
> APIs? Or is there another motivation?
> I'm just curious because it seems like every non-backwards-compatible
> change I have to make to WebCore seems to translate to a similar change to
> the WebKit API (case in point, I'm currently changing parameters to
> MessagePort.postMessage() to take multiple ports instead of a single port
> and this requires changes to things like WebKit::WebChannel), so upstreaming
> the WebKit API wouldn't really shield us from breakage in those cases.
>
> Anyhow, I'm trying to understand the philosophy around when to use classes
> like WebVector (our WebKit API version of Vector).
>
I try to avoid WebVector since it necessitates a copy. I'm not sure that I
really want to keep it in the API long term. It is a crutch to help us out.
On the Chromium side, use std::vector. On the WebKit side, use
WTF::Vector. WebVector should only be used for data exchange, and should
just be a temporary.
In some cases, visitor or iterator patterns can be better than a WebVector.
See WebHTTPHeaderVisitor and WebPluginListBuilder for examples.
-Darin
> I'm updating some of the WebKit API classes to accept a WebVector as a
> parameter as part of the change described above. Down in the calling code,
> should I use STL classes like std::vector, and then convert to WebVector
> only when actually calling into the WebKit API? Or should I use WebVector
> elsewhere in the code (like down in the glue code)? It's certainly more
> efficient *not* to have to convert between std::vector and WebVector if I
> don't have to, but that seems like a slippery slope as WebKit API classes
> would start spreading through the rest of the codebase.
>
> Any guidance for me?
>
> -atw
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
