Move modules-dependent eventtarget code out of core.

Move modules-dependent eventtarget code out of core.
This is a follow-up CL on https://codereview.chromium.org/275283002/

BUG=371581
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=174387

[eseidel, 2014-05-19 21:44:22]

Other than the weirdness with virtual dispatch here, I very much like this
change!

https://codereview.chromium.org/297493004/diff/1/Source/web/WebKit.cpp
File Source/web/WebKit.cpp (right):

https://codereview.chromium.org/297493004/diff/1/Source/web/WebKit.cpp#newcod...
Source/web/WebKit.cpp:172: DEFINE_STATIC_LOCAL(WebCore::ModulesInitializer,
initializer, ());
So why can't we just call WebCore::init() and Modules::init() separately?  Why
do we need this class with virtual dispatch?  It feels like we just want to
split WebCore::init() into two pieces?  Or have Modules::init() register itself
with core so it can be inited when Core::init() is called?

[c.shu, 2014-05-19 21:53:01]

https://codereview.chromium.org/297493004/diff/1/Source/web/WebKit.cpp
File Source/web/WebKit.cpp (right):

https://codereview.chromium.org/297493004/diff/1/Source/web/WebKit.cpp#newcod...
Source/web/WebKit.cpp:172: DEFINE_STATIC_LOCAL(WebCore::ModulesInitializer,
initializer, ());
On 2014/05/19 21:44:23, eseidel wrote:
> So why can't we just call WebCore::init() and Modules::init() separately?  Why
> do we need this class with virtual dispatch?  It feels like we just want to
> split WebCore::init() into two pieces?  Or have Modules::init() register
itself
> with core so it can be inited when Core::init() is called?

Thanks for the review, Eric. The problem was that the init() calls on each
component in WebCore::init() are dependent on the order. We cannot do a list of
calls on Foos::init() and then a list of Foos::initModules(), or vice versa. For
example, EventTargetNames::initModules() has to be called right after
EventTargetNames::init() but not after everything else has been initialized. We
can register EventTargetNames::initModules to core but this is similar to the
virtual function approach, right?

[eseidel, 2014-05-19 22:07:25]

lgtm

[eseidel, 2014-05-19 22:07:57]

I don't have a better solution at present.  Lets take this and iterate from
here.

[c.shu, 2014-05-20 15:51:01]

The CQ bit was checked by c.shu@samsung.com

[commit-bot: I haz the power, 2014-05-20 15:51:14]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/c.shu@samsung.com/297493004/1

[commit-bot: I haz the power, 2014-05-20 17:02:17]

Change committed as 174387