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'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
-~----------~----~----~----~------~----~------~--~---
