Summary: | Even More Objective-C DOM auto-generation cleanup | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Sam Weinig <sam> | ||||
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | ||||||
Priority: | P2 | ||||||
Version: | 420+ | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
Attachments: |
|
Description
Sam Weinig
2006-09-09 12:05:16 PDT
Created attachment 10479 [details]
patch
- Auto-generate some remaining extension methods for DOMDocument and DOMCSSStyleDeclaration.
- Split DOMHTMLEmbedElement into it's own files. It can't be auto-generated yet because the Objective-C interface is significantly different from the implementation interface. Since HTMLEmbedElement is not in the W3C spec, this is somewhat of a gray area.
- Auto-generate DOMEventListener protocol.
- Clean up the IDL files by separating the extensions from the specified methods and attributes.
- Change to use new, more Objectice-C'ish version of DOMKeyboardEvent's initKeyboardEvent. Fixes an error with regression test for fast/events/dblclick-addEventListener.html.
Comment on attachment 10479 [details]
patch
My thoughts
1. not a fan of exclude=JS, it seems to be used for Obj-C only bindings. This only hinders efforts to make other language bindings (like ruby, python, perl, etc.)
2. I don't think the xpath stuff should be included in this patch.
3. xpath stuff shouldn't need OldStyleObjC, since it's never shipped.
Other than that the patch looks fine. r=me (assuming you remove the xpath stuff)
The Xpath changes are fine. And they should use OldStyleObjC since they are in the Private headers and internal Apple clients are using it. We can try to wean them off of the old style and get it removed. (In reply to comment #2) > 1. not a fan of exclude=JS, it seems to be used for Obj-C only bindings. This > only hinders efforts to make other language bindings (like ruby, python, perl, > etc.) I think you have this backwards. exclude=JS is typically used for bindings that we don't want for JS, at the moment at least. For example, there are cases where we have hand-written bindings for JS that the auto-generated bindings would conflict with. I don't know of any examples of true "ObjC-only" bindings. If those did exist, then we'd want an ObjCOnly keyword of some type. I think that the way we're doing it is *better* for other future language bindings. |