[webkit-dev] WebAccessibilityRole must match AccessiblityRole enums?

[Maciej Stachowiak]

On Jun 4, 2010, at 1:32 PM, Darin Fisher wrote:

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

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100610/1714cd19/attachment.html>