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<[email protected]> 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<[email protected]> 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 <[email protected]> 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<[email protected]> 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 <[email protected]> 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 >>> >> [email protected] >>> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > >>> > >>> > >> > >>> > >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
