Freeze all the DOMHTML* Objective-C bindings

• Component: New Bugs
• Status: RESOLVED FIXED

[Anders Carlsson]

Freeze all the DOMHTML* Objective-C bindings

[Anders Carlsson]

Created attachment 285040 [details]
Patch

[Tim Horton]

Comment on attachment 285040 [details]
Patch

rs=me

[Anders Carlsson]

Committed r203988: <http://trac.webkit.org/changeset/203988>

[Darin Adler]

I just noticed that we are generating a lot of Objective-C bindings that then are not migrated by MigrateHeaders. I wonder if we can get away with just not generating any of those?

[Anders Carlsson]

(In reply to comment #4)
> I just noticed that we are generating a lot of Objective-C bindings that
> then are not migrated by MigrateHeaders. I wonder if we can get away with
> just not generating any of those?

Yeah, I've noticed that too. There are a couple of DOMEvent headers that aren't being installed, but they're used in 

Class kitClass(WebCore::Event* impl)

I think we can simply fall back to DOMEvent for them.

[Anders Carlsson]

(In reply to comment #5)
> (In reply to comment #4)
> > I just noticed that we are generating a lot of Objective-C bindings that
> > then are not migrated by MigrateHeaders. I wonder if we can get away with
> > just not generating any of those?
> 
> Yeah, I've noticed that too. There are a couple of DOMEvent headers that
> aren't being installed, but they're used in 
> 
> Class kitClass(WebCore::Event* impl)
> 
> I think we can simply fall back to DOMEvent for them.

There are also CSS related classes that aren't installed but used in

Class kitClass(WebCore::CSSRule* impl)

and

Class kitClass(WebCore::CSSValue* impl)

We can probably get away with returning [DOMCSSRule class] and [DOMCSSValue class] respectively.

[Darin Adler]

There are also lots of others, like the Apple Pay ones.

[Anders Carlsson]

(In reply to comment #7)
> There are also lots of others, like the Apple Pay ones.

Yes, those aren't even built!