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) _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
