RESOLVED FIXED 10791
Even More Objective-C DOM auto-generation cleanup 
https://bugs.webkit.org/show_bug.cgi?id=10791
Summary Even More Objective-C DOM auto-generation cleanup
Sam Weinig
Reported 2006-09-09 12:05:16 PDT
Fix some stuff. Patch and description of changes to come.
Attachments
patch (50.21 KB, patch)
2006-09-09 12:23 PDT, Sam Weinig 		eric: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Sam Weinig
Comment 1 2006-09-09 12:23: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.
Eric Seidel (no email)
Comment 2 2006-09-09 14:16:03 PDT
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)
Timothy Hatcher
Comment 3 2006-09-09 14:24:55 PDT
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.
Sam Weinig
Comment 4 2006-09-09 15:00:29 PDT
Landed in r16277.
Darin Adler
Comment 5 2006-09-10 10:51:07 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.