[webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?

[Darin Fisher]

On Fri, Jun 4, 2010 at 11:15 AM, Peter Kasting <pkasting at google.com> wrote:

> On Fri, Jun 4, 2010 at 11:11 AM, Darin Adler <darin at 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.

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100604/3c443089/attachment.html>