Bug 151739

Created attachment 266427 [details] Patch

Comment on attachment 266427 [details] Patch This seems sort of pointless. I don’t think we’ll be generating Objective-C bindings for partial interfaces. We have different ideas about how to expose DOM to Objective-C and Swift. It’s OK to fix the code generator, but we never plan to use it!

Comment on attachment 266427 [details] Patch Clearing flags on attachment: 266427 Committed r193637: <http://trac.webkit.org/changeset/193637>

All reviewed patches have been landed. Closing bug.

Should ObjC generator skips generating code for ImplementedBy functions and attributes then?

(In reply to comment #5) > Should ObjC generator skips generating code for ImplementedBy functions and > attributes then? I’m not 100% sure we can do exactly that, but we could start doing something along those lines. Generally speaking what we probably want is to keep the existing Objective-C bindings working but not add more to them. Note that there was no problem compiling WebKit even without this bug fix. I don’t know of any actual binding that we compile with Objective-C that was affected by this fix. There are many new DOM APIs where we don’t have a good mapping to Objective-C in the bindings, but it doesn’t matter if we do not try to expose those new DOM APIs.

(In reply to comment #6) > (In reply to comment #5) > > Should ObjC generator skips generating code for ImplementedBy functions and > > attributes then? > > I’m not 100% sure we can do exactly that, but we could start doing something > along those lines. Generally speaking what we probably want is to keep the > existing Objective-C bindings working but not add more to them. > > Note that there was no problem compiling WebKit even without this bug fix. I > don’t know of any actual binding that we compile with Objective-C that was > affected by this fix. The affected code is in the new Web Animations impl - see bug 151688 Web Animations defines an extension to the Document interface. http://w3c.github.io/web-animations/#extensions-to-the-document-interface > > There are many new DOM APIs where we don’t have a good mapping to > Objective-C in the bindings, but it doesn’t matter if we do not try to > expose those new DOM APIs. So what's the mechanism for not exposing those APIs to Objective-C?

(In reply to comment #7) > So what's the mechanism for not exposing those APIs to Objective-C? We have multiple mechanisms, none really elegant, and could add more. One approach is to use one of these in IDL files: #if !defined(LANGUAGE_OBJECTIVE_C) || !LANGUAGE_OBJECTIVE_C #if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT Another approach is that CodeGeneratorObjC.pm will omit certain thing entirely based on attributes or other aspects of the IDL. For example, I removed support for nullables entirely recently, so they are just ignored, similarly [Private] functions are ignored, [CustomBinding] items are ignored, [EventHandler] items are ignored. Another approach is to list filenames to skip in this DerivedSources.make line: OBJC_DOM_HEADERS=$(filter-out DOMDOMWindow.h DOMDOMMimeType.h DOMDOMPlugin.h,$(OBJC_DOM_CLASSES:%=DOM%.h)) Two more peculiar things about Objective-C DOM: 1) only things listed in bindings/objc/PublicDOMInterfaces.h get to be API; others are considered non-public SPI on OS X 2) the Objective-C DOM doesn't exist at all on iOS

(In reply to comment #8) > (In reply to comment #7) > > So what's the mechanism for not exposing those APIs to Objective-C? > > We have multiple mechanisms, none really elegant, and could add more. One > approach is to use one of these in IDL files: > > #if !defined(LANGUAGE_OBJECTIVE_C) || !LANGUAGE_OBJECTIVE_C > #if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT For now, we've chosen to adopt this method and won't expose the web animations API to Objective-C. See bug 151688.