Bug 161185 – Add the ability to override the implementation name of IDL enums and dictionaries

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Sam Weinig]

Add the ability to override the implementation name of IDL enums and dictionaries

[Sam Weinig]

Created attachment 286985 [details]
Patch

[Sam Weinig]

Committed revision 204978.

[Chris Dumez]

Comment on attachment 286985 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=286985&action=review

> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:810
> +    if ($codeGenerator->HasEnumImplementationNameOverride($name)) {

Isn't this a bit overkill? Why don't we just check the ImplementedAs extended attribute here?
Then we wouldn't need to update CodeGenerator.pm at all, right?

> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:929
> +    if ($codeGenerator->HasDictionaryImplementationNameOverride($name)) {

Isn't this a bit overkill? Why don't we just check the ImplementedAs extended attribute here?
Then we wouldn't need to update CodeGenerator.pm at all, right?

[Darin Adler]

I’m kind of sad we needed this. I liked the idea of doing it all just by putting "using" in the various classes.

[Chris Dumez]

(In reply to comment #4)
> I’m kind of sad we needed this. I liked the idea of doing it all just by
> putting "using" in the various classes.

FYI, Simon tried this for DOMWindow::ScrollToOptions / Element::ScrollToOptions and got the following linking error:
duplicate symbol __ZN7WebCore17convertDictionaryINS_15ScrollToOptionsEEEN3WTF8OptionalIT_EERN3JSC9ExecStateENS6_7JSValueE in: OpenSource/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/x86_64/JSDOMWindow.o  OpenSource/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/x86_64/JSElement.o

[Darin Adler]

(In reply to comment #5)
> FYI, Simon tried this for DOMWindow::ScrollToOptions /
> Element::ScrollToOptions and got the following linking error:
> duplicate symbol
> __ZN7WebCore17convertDictionaryINS_15ScrollToOptionsEEEN3WTF8OptionalIT_EERN3
> JSC9ExecStateENS6_7JSValueE in:
> OpenSource/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/
> x86_64/JSDOMWindow.o 
> OpenSource/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/
> x86_64/JSElement.o

Very interesting. We need to consider how to work around this. One trick might be to mark the functions inline even if they don’t actually get inlined. Or make them templates even though they don’t need to be. But maybe there’s a better solution.

[Chris Dumez]

(In reply to comment #6)
> (In reply to comment #5)
> > FYI, Simon tried this for DOMWindow::ScrollToOptions /
> > Element::ScrollToOptions and got the following linking error:
> > duplicate symbol
> > __ZN7WebCore17convertDictionaryINS_15ScrollToOptionsEEEN3WTF8OptionalIT_EERN3
> > JSC9ExecStateENS6_7JSValueE in:
> > OpenSource/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/
> > x86_64/JSDOMWindow.o 
> > OpenSource/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/
> > x86_64/JSElement.o
> 
> Very interesting. We need to consider how to work around this. One trick
> might be to mark the functions inline even if they don’t actually get
> inlined. Or make them templates even though they don’t need to be. But maybe
> there’s a better solution.

I think that if we enabled sharing of dictionaries between IDL files, some of the trouble would go away. Right now, ScrollToOptions is duplicated in DOMWindow.idl and Element.idl that the parsing code is generated twice.

[Sam Weinig]

(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > FYI, Simon tried this for DOMWindow::ScrollToOptions /
> > > Element::ScrollToOptions and got the following linking error:
> > > duplicate symbol
> > > __ZN7WebCore17convertDictionaryINS_15ScrollToOptionsEEEN3WTF8OptionalIT_EERN3
> > > JSC9ExecStateENS6_7JSValueE in:
> > > OpenSource/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/
> > > x86_64/JSDOMWindow.o 
> > > OpenSource/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/
> > > x86_64/JSElement.o
> > 
> > Very interesting. We need to consider how to work around this. One trick
> > might be to mark the functions inline even if they don’t actually get
> > inlined. Or make them templates even though they don’t need to be. But maybe
> > there’s a better solution.
> 
> I think that if we enabled sharing of dictionaries between IDL files, some
> of the trouble would go away. Right now, ScrollToOptions is duplicated in
> DOMWindow.idl and Element.idl that the parsing code is generated twice.

What is the plan for that? Should we pull all dictionaries / enumerations out into their own idl files and have them generate their own .h/cpp files? If we do that, how will the code generator know that a type is a dictionary and not an interface type? Should we generate a type mapping for all types up front? Do it lazily? So many questions.