There are plenty of other bindings - Gtk has a set of dom bindings i believe, there used to be COM (shudder) bindings as well, but those aren't the problem. We could have as many binding languages as we want, there's no major architectural reason not to.
But supporting javascript isn't simply a matter of another binding. The complexity comes from javascript being the internal scripting language used by webcore for script tags, etc. It's that complexity that creates the need for massive abstraction when supporting multiple distinct JS engines. There is simply no way to support multiple JS engines without retaining the current abstraction - the fact that it's currently only present in order to support the existence of V8 isn't relevant - the same machinery would be necessary to support _any_ other JS engine in addition to JSC. There is strictly no advantage to WebKit in keeping that machinery, it is purely performance and opportunity cost. You need an _extremely_ compelling argument to outweigh those costs. --Oliver On Apr 4, 2013, at 11:15 PM, Per Bothner <per.both...@oracle.com> wrote: > On 04/04/2013 09:14 PM, Ryosuke Niwa wrote: >> On the other hand, I don't think optimizing WebCore for JSC doesn't >> necessarily mean it'll become impossible for you to have a custom build >> of WebKit that uses some other binding code. For example, Mac has >> Objective-C bindings and that's not going anywhere in the foreseeable >> future. > > True, but Objective-C bindings are *in addition* to JSC. > Our use of Nashorn *replaces* JSC. > > Still, we can certainly have local changes in the code-base, > like we currently do. My worry is about the places the code > hard-wires in an assumption on JSC - if those proliferate > it will complicate us keeping updated with WebKit. > > I can see the logic for simplifying, and I'm not asking you > to support an alternative JavaScript engine where it > complicates the code. Just please keep in mind there are people > who use WebKit *without* JSC. > -- > --Per Bothner > per.both...@oracle.com p...@bothner.com http://per.bothner.com/ > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
