Add gin, a lightweight bindings system for V8

This CL introduces a lightweight bindings system for V8 called gin

Unlike the extensions V8 bindings, gin is based on ObjectTemplates rather than
on evaluating script.  Unlike the Blink V8 bindings, gin isn't tightly coupled to
Blink.  In fact, gin's only link-time dependency is V8.  We plan to use gin to build
the V8 bindings for Mojo (see https://codereview.chromium.org/59153005/ for
an example of how they will be used).

In the long term, gin could serve as a basis for both the Blink and the extension
system bindings, but we don't have any immediate plans to pursue that use of
this code.

This code is largely inspired by a lightweight bindings system designed by
Aaron Boodman.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=234160

[abarth-chromium, 2013-11-09 11:51:25]

I've extracted the non-Mojo specific parts of mojo/public/bindings/js into a new
top-level directory, as requested.  PTAL.  Thanks!

[darin (slow to review), 2013-11-09 16:32:04]

LGTM for adding this as a top-level module. Please announce on chromium-dev.

I haven't reviewed the details. I defer to you two for that.
On Nov 9, 2013 3:51 AM, <abarth@chromium.org> wrote:

> Reviewers: Aaron Boodman, darin,
>
> Message:
> I've extracted the non-Mojo specific parts of mojo/public/bindings/js into
> a new
> top-level directory, as requested.  PTAL.  Thanks!
>
> Description:
> This CL introduces a lightweight bindings system for V8 called gin
>
> Unlike the extensions V8 bindings, gin is based on ObjectTemplates rather
> than
> on evaluating script.  Unlike the Blink V8 bindings, gin isn't tightly
> coupled
> to
> Blink.  In fact, gin's only link-time dependency is V8.  We plan to use
> gin to
> build
> the V8 bindings for Mojo (see https://codereview.chromium.org/59153005/for
> an example of how they will be used).
>
> In the long term, gin could serve as a basis for both the Blink and the
> extension
> system bindings, but we don't have any immediate plans to pursue that use
> of
> this code.
>
> This code is largely inspired by a lightweight bindings system designed by
> Aaron Boodman.
>
> Please review this at https://codereview.chromium.org/67763002/
>
> SVN Base: svn://svn.chromium.org/chrome/trunk/src
>
> Affected files (+1032, -8 lines):
>   M build/all.gyp
>   A gin/DEPS
>   A + gin/OWNERS
>   A gin/README
>   A gin/array_buffer.h
>   A gin/array_buffer.cc
>   A gin/converter.h
>   A gin/converter.cc
>   A gin/converter_unittest.cc
>   A gin/gin.gyp
>   A + gin/initialize.h
>   A gin/initialize.cc
>   A gin/per_isolate_data.h
>   A gin/per_isolate_data.cc
>   A gin/runner.h
>   A gin/runner.cc
>   A gin/runner_unittest.cc
>   A + gin/test/run_all_unittests.cc
>   A gin/test/v8_test.h
>   A gin/test/v8_test.cc
>   A gin/wrapper_info.h
>   A gin/wrapper_info.cc
>
>
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[darin1, 2013-11-09 16:34:39]

Also, I think there is a target in addition to all that you want to use so
that the try bots build this as well.
On Nov 9, 2013 8:32 AM, "Darin Fisher" <darin@chromium.org> wrote:

> LGTM for adding this as a top-level module. Please announce on
> chromium-dev.
>
> I haven't reviewed the details. I defer to you two for that.
> On Nov 9, 2013 3:51 AM, <abarth@chromium.org> wrote:
>
>> Reviewers: Aaron Boodman, darin,
>>
>> Message:
>> I've extracted the non-Mojo specific parts of mojo/public/bindings/js
>> into a new
>> top-level directory, as requested.  PTAL.  Thanks!
>>
>> Description:
>> This CL introduces a lightweight bindings system for V8 called gin
>>
>> Unlike the extensions V8 bindings, gin is based on ObjectTemplates rather
>> than
>> on evaluating script.  Unlike the Blink V8 bindings, gin isn't tightly
>> coupled
>> to
>> Blink.  In fact, gin's only link-time dependency is V8.  We plan to use
>> gin to
>> build
>> the V8 bindings for Mojo (see https://codereview.chromium.org/59153005/for
>> an example of how they will be used).
>>
>> In the long term, gin could serve as a basis for both the Blink and the
>> extension
>> system bindings, but we don't have any immediate plans to pursue that use
>> of
>> this code.
>>
>> This code is largely inspired by a lightweight bindings system designed by
>> Aaron Boodman.
>>
>> Please review this at https://codereview.chromium.org/67763002/
>>
>> SVN Base: svn://svn.chromium.org/chrome/trunk/src
>>
>> Affected files (+1032, -8 lines):
>>   M build/all.gyp
>>   A gin/DEPS
>>   A + gin/OWNERS
>>   A gin/README
>>   A gin/array_buffer.h
>>   A gin/array_buffer.cc
>>   A gin/converter.h
>>   A gin/converter.cc
>>   A gin/converter_unittest.cc
>>   A gin/gin.gyp
>>   A + gin/initialize.h
>>   A gin/initialize.cc
>>   A gin/per_isolate_data.h
>>   A gin/per_isolate_data.cc
>>   A gin/runner.h
>>   A gin/runner.cc
>>   A gin/runner_unittest.cc
>>   A + gin/test/run_all_unittests.cc
>>   A gin/test/v8_test.h
>>   A gin/test/v8_test.cc
>>   A gin/wrapper_info.h
>>   A gin/wrapper_info.cc
>>
>>
>>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Aaron Boodman, 2013-11-09 21:40:34]

Cooool. I expect ArgumentParser will also end up here?

LGTM - you decide whether to do another round of review or not.

https://codereview.chromium.org/67763002/diff/40001/gin/README
File gin/README (right):

https://codereview.chromium.org/67763002/diff/40001/gin/README#newcode1
gin/README:1: gin - Lightweight bindings for V8
Nit: Can we capitalize 'gin' when it is used in English text?

https://codereview.chromium.org/67763002/diff/40001/gin/converter.h
File gin/converter.h (right):

https://codereview.chromium.org/67763002/diff/40001/gin/converter.h#newcode109
gin/converter.h:109: inline v8::Handle<v8::String> StringToV8(
Why is this needed?

https://codereview.chromium.org/67763002/diff/40001/gin/per_isolate_data.h
File gin/per_isolate_data.h (right):

https://codereview.chromium.org/67763002/diff/40001/gin/per_isolate_data.h#ne...
gin/per_isolate_data.h:25: v8::Handle<v8::Object> CreateObject(WrapperInfo*
info);
Seems a little odd to have CreateObject() here, rather than on the class that
creates the object template. If that is just to share the caching code, then you
could define something like:

template<typename T>
struct V8ClassConverter : public V8Converter<T> {
 ...
};

and have that guy have a private method that knows how to interact with
PerIsolateData, and which also calls a specialized CreateTemplate() method that
the templatized struct is expected to define.

https://codereview.chromium.org/67763002/diff/40001/gin/runner.h
File gin/runner.h (right):

https://codereview.chromium.org/67763002/diff/40001/gin/runner.h#newcode1
gin/runner.h:1: // Copyright 2013 The Chromium Authors. All rights reserved.
I don't see what runner is used by in this cl?

[abarth-chromium, 2013-11-10 02:12:19]

Thanks for the review!  I'm going to address your comments below and land this
CL so we can iterate.

> I expect ArgumentParser will also end up here?

Yeah, I think that would make sense.  I'll add it in the next CL when we have a
caller.

https://codereview.chromium.org/67763002/diff/40001/gin/README
File gin/README (right):

https://codereview.chromium.org/67763002/diff/40001/gin/README#newcode1
gin/README:1: gin - Lightweight bindings for V8
On 2013/11/09 21:40:35, Aaron Boodman wrote:
> Nit: Can we capitalize 'gin' when it is used in English text?

Sure.

https://codereview.chromium.org/67763002/diff/40001/gin/converter.h
File gin/converter.h (right):

https://codereview.chromium.org/67763002/diff/40001/gin/converter.h#newcode109
gin/converter.h:109: inline v8::Handle<v8::String> StringToV8(
On 2013/11/09 21:40:35, Aaron Boodman wrote:
> Why is this needed?

Two reasons:

1) So you can write StringToV8("foo").  The compiler isn't smart enough to guess
that you want to convert the string literal to std::string.  We could add a
const char* specialization for that case if we wanted.

2) To specialize the return value to v8::Handle<v8::String>.  There are some V8
APIs that want strings specifically (e.g., v8::Script::New).  Having a helper
function that knows the return type lets us avoid writing the cast all the time.

https://codereview.chromium.org/67763002/diff/40001/gin/per_isolate_data.h
File gin/per_isolate_data.h (right):

https://codereview.chromium.org/67763002/diff/40001/gin/per_isolate_data.h#ne...
gin/per_isolate_data.h:25: v8::Handle<v8::Object> CreateObject(WrapperInfo*
info);
On 2013/11/09 21:40:35, Aaron Boodman wrote:
> Seems a little odd to have CreateObject() here, rather than on the class that
> creates the object template. If that is just to share the caching code, then
you
> could define something like:
> 
> template<typename T>
> struct V8ClassConverter : public V8Converter<T> {
>  ...
> };
> 
> and have that guy have a private method that knows how to interact with
> PerIsolateData, and which also calls a specialized CreateTemplate() method
that
> the templatized struct is expected to define.

For now, I think I'm just going to remove this function.  There aren't any
callers yet and we can figure out the best thing when we have the first caller. 
I thought for a while we could avoid allocating a new local handle when creating
the object, but we need to do that anyway, so you're right that we should
probably just have PerIsolateData vend a v8::Local<v8::ObjectTemplate> and call
NewInstance somewhere else.

https://codereview.chromium.org/67763002/diff/40001/gin/runner.h
File gin/runner.h (right):

https://codereview.chromium.org/67763002/diff/40001/gin/runner.h#newcode1
gin/runner.h:1: // Copyright 2013 The Chromium Authors. All rights reserved.
On 2013/11/09 21:40:35, Aaron Boodman wrote:
> I don't see what runner is used by in this cl?

Currently it's just used in runner_unittest.cc.  It's going to be the main entry
point to actually executing script.

We can talk through this more, but what I had in mind for Mojo is that we
wouldn't put much of anything into the global scope.  Instead, we'd run the
app's script by calling its "main" function with an interface object that
contained the API.  There are a number of benefits to this approach:

1) We can potentially snapshot apps just before calling main.  Because they
don't have any APIs yet, they can't have much effect on the outside world.  On
subsequent runs, we can start them up faster.

2) The app has greater control over the structure of its code because other code
it loads doesn't automatically have access to the underlying API.  For example,
the script can create a new API and hide the Mojo API inside closures.  If the
script stays inside the SES subset, then it might be able to load untrusted
script into its global object.

[commit-bot: I haz the power, 2013-11-10 02:13:53]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/abarth@chromium.org/67763002/210001

[commit-bot: I haz the power, 2013-11-10 05:00:51]

Change committed as 234160