[webkit-dev] Sharing code between WebCore/bindings/js and WebCore/bindings/v8

[Maciej Stachowiak]

On May 27, 2009, at 11:47 AM, Adam Barth wrote:

> I've been doing some work recently in our JavaScript bindings.  As
> part of this work, I've noticed that WebCore/bindings/js and
> WebCore/bindings/v8 have drifted apart in some details.  It's kind of
> ridiculous that we have so much duplicated code in these two folders.
> We should try to re-organize our bindings to share as much code as
> possible.
>
> 1) Where should the common code live?  One option is to have:
>
> WebCore/bindings/js  <--- common code
> WebCore/bindings/jsc  <--- JSC specific
> WebCore/bindings/v8  <--- V8 specific
>
> 2) How much should we try to share?  For example, we could have an
> abstracted notion of ArgList that works for both engines, or we could
> be happy to factor out common routines like createWindow
> <http://trac.webkit.org/browser/trunk/WebCore/bindings/js/JSDOMWindowCustom.cpp#L285 
> >.
>
> I presume Sam is a good contact for the JSC bindings.  Who's a good
> contact for the V8 bindings?

It's definitely unfortunate that the bindings keep going out of sync.  
I have two concerns though:

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:

     1.a) We're not super keen on refactorings that wouldn't be  
justified just for JSC itself. If there is shareable code that is  
easily factored out without adding otherwise needless abstraction or  
layers of indirection, that's fine, but we don't want to add  
indirection that would add any code complexity or runtime cost.

     1.b) We couldn't commit to not breaking the v8 bindings when  
hacking on the shared layer, if there was one.

2) My understanding is that the v8 bindings are not even fully merged  
into the WebKit tree yet - many pieces live externally in the Chromium  
repository. So we couldn't meaningfully maintain the v8 bindings even  
if we wanted to, and would have no good way to evaluate the soundness  
of the shared layer.

Again, I am sure maintaining a second set of JS bindings is annoying,  
but the Chrome team felt it was worth the cost to have a separate JS  
engine, and committed to taking on the burden.

Regards,
Maciej