Great idea to make some improvements. I think there are many opportunities for the code generators to share code instead of being copy/pasted/modified versions of one another. When changing the scripts we should look for opportunities to do that.
I love the part of this where you will remove support for attributes that are unused. Lets do that ASAP! The part where we have some properties in IDLs that no code generator is looking at might require a tiny bit more research. But once you do figure out the original intent and you are sure we can just remove these, it is a huge win! Removing without being sure is not quite as good. 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. Renaming properties to match the specification is also a neat idea. To get the full benefit from that it would probably need to go hand in hand with using the syntax from the specification, which puts the attributes somewhere different. 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 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. 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. -- Darin _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
