Initial patch for the web modules layered platform proposal.

Initial patch for the web modules layered platform proposal.

This reads in the IDL we use to expose APIs to the web platform and
instead generates C++ bindings to expose to Blink developers. The C++
bindings are a very simple wrapper around a pointer to the core C++
class.  Compilers will completely compile out the wrapper and there is
no performance overhead compared to writing the raw C++ code.

This patch just adds the plumbing to expose Node::firstChild. There will
need to be followup patches to expose more types of methods and more classes.
The IDL compiler is two phases. The parser, which generates an intermediate
representation (IR), and the codegen that generates the C++ code from the IR.
We share the parser code with the V8 code generator, but don't share the code
to generate the C++ bindings from the IR.

Using this we can build features in a layered way. It's not quite as true to the
layered platform vision as writing the features in JS code, but it's a big
pragmatic step in that direction.

[esprehn, 2015-07-22 02:25:10]

esprehn@chromium.org changed reviewers:
+ esprehn@chromium.org

[esprehn, 2015-07-22 02:25:11]

I don't think we want to call it a WebModuleNode that'll make all code using
this so verbose. I think you want to just put it in another namespace.

namespace blink {
namespace webmodules {

class Node {
  blink::Node* m_wrapped;
}

}
}

then you can do a using webmodules directive to avoid typing super verbose
names.

It also occurs to me we need to forward the ref/deref methods so you can do
RefPtr<webmodules::Node> and have it work

[dglazkov, 2016-07-29 22:26:27]

A couple of thoughts, a year later.

1) I think we should just always run both v8 and webmodules pass, rather than
have a flag

2) We should generate WebModules for all IDL attributes/methods, and blacklist
those we don't like.

WDYT?

I can take this patch and see what I can do.

[ojan, 2016-07-30 03:36:46]

On 2016/07/29 at 22:26:27, dglazkov wrote:
> A couple of thoughts, a year later.
> 
> 1) I think we should just always run both v8 and webmodules pass, rather than
have a flag

SGTM. I had a bit of trouble getting it working as one pass, so I went with what
was easiest since I didn't see a clear benefit in either direction.
 
> 2) We should generate WebModules for all IDL attributes/methods, and blacklist
those we don't like.

That sounds right, but it might be hard to make all the IDL attributes/methods
work in one patch?

> I can take this patch and see what I can do.

\o/

[haraken, 2016-07-30 15:35:01]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org

[haraken, 2016-07-30 15:35:02]

The overall direction looks good to me. Once the CL is ready, we might want to
ask yukishiino@ or bashi@ for the IDL compiler review.

https://codereview.chromium.org/1248043003/diff/1/Source/bindings/templates/w...
File Source/bindings/templates/web_modules_interface.h (right):

https://codereview.chromium.org/1248043003/diff/1/Source/bindings/templates/w...
Source/bindings/templates/web_modules_interface.h:1: {% include
'copyright_block.txt' %}

You can add a test to bindings/tests/idls/.

https://codereview.chromium.org/1248043003/diff/1/Source/core/core.gypi
File Source/core/core.gypi (right):

https://codereview.chromium.org/1248043003/diff/1/Source/core/core.gypi#newcode7
Source/core/core.gypi:7: 'dom/Node.idl',

It's a bit unfortunate that we need to list up IDL files that have
[WebModulesExposed]. Can we generate the list automatically? (You don't need to
address in this CL though.)