On Jun 4, 2010, at 1:32 PM, Darin Fisher wrote: > On Fri, Jun 4, 2010 at 11:15 AM, Peter Kasting <pkast...@google.com> wrote: > On Fri, Jun 4, 2010 at 11:11 AM, Darin Adler <da...@apple.com> wrote: > If the two enum types are identical except for their names, then this doesn’t > firewall the types at all. > > It doesn't firewall the concepts (but then, it's hard for an embedding layer > to not transmit any concepts, as that's basically the point). It does > firewall the actual #includes, and thus provides source independence for the > embedder/a point where the WebKit side can be built as its own independent > DLL (if we want to). > > PK > > > Right. Insulating the embedder from WebCore headers is very important. It > helps avoid accidental dependencies on more of WebCore than just simple > constant values. > > I can imagine a tool that would parse a WebCore enum and convert it to a > WebKit API equivalent, but that seems dangerous as it would mean that a > WebCore change could change the API. I think it is better for API changes to > be more explicit. > > I also agree with Peter that a case-switch translation would be no less work > to maintain. Our use of compile-time asserts catches any drift between the > enum values (with the exception of newly appended WebCore enum values). > However, a case-switch translation may become necessary if a WebCore enum > value were deleted. Then we'd need to make a decision between either > deleting the corresponding API enum value or providing compatible support for > it somehow. If we chose the latter, then the API enum and the WebCore enum > would no longer be 1-1, so we'd need a case-switch translation to cope.
With a case-switch transition, the compiler can also help you detect cases where a new enum value was added at the core level but not the API level. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
