[webkit-dev] WebKit IDL cleanup
Kentaro Hara
haraken at chromium.org
Wed Feb 1 16:11:10 PST 2012
Thanks, darin. I'll start the cleanup from today.
> I’d like to see us give an error when we see unimplemented attributes used. This would require having a shared list of attributes used by all the code generators.
Good idea!
> Adding a JS prefix to all the properties that are not needed for V8 is something I’m neutral about. It would be nicer if we could remove some of those properties instead, but it seems OK for the presence of V8 to make the WebKit JavaScript engine need a prefix; originally I thought of WebKit JavaScript as the “main binding”.
I see your point. But IMO, I would prefer adding the JS prefix to
distinguish the attributes widely used in all code generators and the
attributes used in JS only. I guess the distinction would help people
understand the role of IDL attributes. Some existing JS-specific
attributes already have the JS (or JSC) prefix.
> I do not like the idea of hardcoding more class names into the code generator to remove properties like CustomDefineSetter. That seems the wrong direction. I’d want to go the other direction and cut down hardcoding of class names and other knowledge to the absolute minimum, even if it means we have a few properties that we wouldn’t otherwise need.
Makes sense. Then let us remove IDLs and hardcode class names only if
the class is DOMWindow. DOMWindow is likely to require special code
and there are already many 'if ($class eq "DOMWindow")' in code
generators. Thus it would make sense to remove IDLs which are used by
DOMWindow only.
> I am also not sure that writing more custom bindings is ever something I would be happy about. There’s a benefit to keeping the total amount of custom binding code down, especially when making improvements to how the bindings work with the underlying language engines.
Makes sense.
Anyway I'll start the work from non-controversial stuff:-) Thanks!
--
Kentaro Hara, Tokyo, Japan (http://haraken.info)
More information about the webkit-dev
mailing list