I agree. I was thinking about looking into this (once LocalStorage is working). Besides the fact that we have more custom code than we should have, a good portion of the .dll is just generated code. It seems like we should be able to strike a better balance of doing things dynamically vs statically in the binding code.
J On Mon, Jun 22, 2009 at 12:02 PM, Aaron Boodman <a...@chromium.org> wrote: > One thing I'd really like to see is a reduction in the amount of > custom bindings code. I am terrified by the number of subtle bugs that > must be hiding in there. It seems like teaching the IDL parser and > code generator on the WebKit side about more WebIDL-isms would help > with this, since a lot of the custom bindings deal with things like > function references. > > - a > > On Mon, Jun 22, 2009 at 11:25 AM, Eric Seidel<esei...@chromium.org> wrote: > > > > I'm still not enthused about WebKit having 2 different JavaScript > > engines. ;) But that's a discussion for another time... > > > > -eric > > > > On Mon, Jun 22, 2009 at 10:54 AM, Jeremy Orlow<jor...@chromium.org> > wrote: > >> I'm not so sure [1]....but we can ask. > >> J > >> [1] > http://lists.macosforge.org/pipermail/webkit-dev/2009-May/007960.html > >> "1) We weren't super enthusiastic about the master WebKit tree trying > >> > >> to support two different JavaScript engines. But we finally agreed > >> when the Chrome folks said this was a hard requirement to merge, and > >> promised they would take on absolutely 100% of the maintenance burden > >> > >> and impose no cost on the rest of the WebKit project. As a result:" > >> > >> On Mon, Jun 22, 2009 at 10:48 AM, Eric Seidel <esei...@chromium.org> > wrote: > >>> > >>> If our binding code is already upstream by then, Darin may be able to > >>> keep Chromium building throughout the process. > >>> https://bugs.webkit.org/show_bug.cgi?id=26567 > >>> > >>> On Mon, Jun 22, 2009 at 9:53 AM, Jeremy Orlow<jor...@chromium.org> > wrote: > >>> > FYI from the webkit mailing list. > >>> > > >>> > We'll probably want to prepare a similar CL for our binding > generating > >>> > code > >>> > and whoever is doing the merges should look out for this change being > >>> > landed. > >>> > > >>> > J > >>> > > >>> > On Sun, Jun 21, 2009 at 10:46 PM, Darin Adler <da...@apple.com> > wrote: > >>> >> > >>> >> The IDL file format we use to generate our bindings has some things > in > >>> >> common with WebIDL and many differences. There are extended > attributes > >>> >> we > >>> >> use that exist in WebIDL but with a different name. > >>> >> > >>> >> As a first step in making our IDL syntax be as close to the WebIDL > >>> >> standard as possible, I’d like to move our extended attributes so > they > >>> >> go in > >>> >> the appropriate place in the syntax. Ours currently come later in an > >>> >> attribute definition; WebIDL puts them before the attribute > definition. > >>> >> > >>> >> I have a patch to do this in this bug > >>> >> <https://bugs.webkit.org/show_bug.cgi?id=26398>. Currently the > patch > >>> >> contains the code changes to make the binding machinery parse the > new > >>> >> syntax, and a couple hand-converted files. > >>> >> > >>> >> I plan to write a script to convert all the IDL files to the new > >>> >> syntax. > >>> >> Should be easy. > >>> >> > >>> >> Not sure about what impact this will have for V8. > >>> >> > >>> >> -- Darin > >>> >> > >>> >> _______________________________________________ > >>> >> webkit-dev mailing list > >>> >> webkit-...@lists.webkit.org > >>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >>> > > >>> > > >>> > >> > > >>> > > >> > >> > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
