Implement lazy JS module initialisation.

Implement lazy JS module initialisation.

The existing lazy JS object code only allows single objects to be evaluated
lazily, but a common pattern in existing modules is to define multiple objects
and functions in the same closure and attach them as various fields on an
existing object, which that interface doesn't provide for. The approach
implemented in this change leverages the module system by allowing clients to
set 'lazy fields' on already existing objects, which when accessed evaluate to
a given field in a given module.


BUG=104100
TEST=unit tests provided


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=128131

[not at google - send to devlin, 2012-03-22 00:35:53]

lgtm, nice.

As discussed, also add a test which sets some of these lazy fields to make sure
you can't, like, crash the renderer that way.

Do you plan on converting all APIs to be lazily loaded after this?

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system.cc
File chrome/renderer/module_system.cc (right):

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system.c...
chrome/renderer/module_system.cc:83: v8::Handle<v8::Value>
ModuleSystem::GetterRouter(
RequireLazyField?

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system.h
File chrome/renderer/module_system.h (right):

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system.h...
chrome/renderer/module_system.h:68: static v8::Handle<v8::Value>
GetterRouter(v8::Local<v8::String> property,
Documentation.

Though does this need to be public? Does it even need to be in the header file?

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system_u...
File chrome/renderer/module_system_unittest.cc (right):

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system_u...
chrome/renderer/module_system_unittest.cc:176:
module_system_->SetLazyField(object, "blah", "lazy", "x");
can you do the same sort of thing you did below, though? have a
variable/counter/whatever set in the required code and ensure that it hasn't
been executed before evaluating object.blah?

[koz (OOO until 15th September), 2012-03-22 01:13:00]

I've added a test for assigning to lazy fields - assignment works as per usual.

Next steps from here are to see if we can make the app and webstore stuff lazy
loaded, which I think will have a positive effect on page load time. The stuff
that uses schema_generated_bindings can be converted to be lazy loaded as well,
but that will require a pretty large refactor, so I'm not sure how high priority
that is.

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system.cc
File chrome/renderer/module_system.cc (right):

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system.c...
chrome/renderer/module_system.cc:83: v8::Handle<v8::Value>
ModuleSystem::GetterRouter(
On 2012/03/22 00:35:53, kalman wrote:
> RequireLazyField?

Yes, or even better - LazyFieldAccessor.

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system.h
File chrome/renderer/module_system.h (right):

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system.h...
chrome/renderer/module_system.h:68: static v8::Handle<v8::Value>
GetterRouter(v8::Local<v8::String> property,
On 2012/03/22 00:35:53, kalman wrote:
> Documentation.
> 
> Though does this need to be public? Does it even need to be in the header
file?

I've made it private, but it does need to be a member of this class, and
therefore in the header file, because it calls private methods on ModuleSystem.

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system_u...
File chrome/renderer/module_system_unittest.cc (right):

http://codereview.chromium.org/9812025/diff/1/chrome/renderer/module_system_u...
chrome/renderer/module_system_unittest.cc:176:
module_system_->SetLazyField(object, "blah", "lazy", "x");
On 2012/03/22 00:35:53, kalman wrote:
> can you do the same sort of thing you did below, though? have a
> variable/counter/whatever set in the required code and ensure that it hasn't
> been executed before evaluating object.blah?

That's a good idea for a test. I've added it as a separate test because it's an
orthogonal concern to this test, I think.

[commit-bot: I haz the power, 2012-03-22 01:19:02]

Change committed as 128131