[WIP Prototype] ES6 https://html.spec.whatwg.org/#fetch-a-single-module-script implementation

third_party/WebKit/Source/bindings/core/v8/ScriptModuleResolver.h

Index: third_party/WebKit/Source/bindings/core/v8/ScriptModuleResolver.h
diff --git a/third_party/WebKit/Source/bindings/core/v8/ScriptModuleResolver.h b/third_party/WebKit/Source/bindings/core/v8/ScriptModuleResolver.h
new file mode 100644
index 0000000000000000000000000000000000000000..a4a039f89d5c9873b83da76e2b58e395829a978d
--- /dev/null
+++ b/third_party/WebKit/Source/bindings/core/v8/ScriptModuleResolver.h
@@ -0,0 +1,36 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef ScriptModuleResolver_h
+#define ScriptModuleResolver_h
+
+#include "platform/heap/Handle.h"
+#include "wtf/text/WTFString.h"
+
+namespace blink {
+
+class ScriptModule;
+class ScriptModuleIdentifier;
+class ModuleScript;
+
+// The ScriptModuleResolver interface is used from V8 module bindings

[dominicc (has gone to gerrit), 2017/01/11 03:23:47]

Hmm, not sure about this comment. This is an interface, and the comment
describes what a particular implementation does. I think what you're trying to
say here is "we need this interface because bindings needs the script module's
descendants, but that information is in core/dom"?

[kouhei (in TOK), 2017/01/17 05:26:13]

Done.

+// to resolve script module descendents references stored in core/dom module
+// implementation.
+class ScriptModuleResolver : public GarbageCollected<ScriptModuleResolver> {

[haraken, 2017/01/11 02:31:28]

I'm not sure if this should be in bindings/ or core/. If this is a pure
interface, we can just place it in core/.

bindings/ is basically a collection of classes that heavily uses V8 APIs.

[kouhei (in TOK), 2017/01/17 05:26:13]

Done.

+ public:
+  DEFINE_INLINE_VIRTUAL_TRACE() {}
+
+  // Called from ModuleMap to observe all fetched ModuleScript instances which

[dominicc (has gone to gerrit), 2017/01/11 03:23:47]

Maybe rephrase this, it sounds like ModuleMap is doing the observing, but it's
the resolver which is the observer (I think?) Maybe rephrase from the point of
view of the caller:

Notify the ScriptModuleResolver that a ModuleScript exists.

(Why is this needed, BTW?)

There's another problem here--these comments introduce a lot of nouns like
descendants, referrer and resolver. Maybe give some hints in the class comment,
something like:

When a module writes import 'x', the module is called the referrer, 'x' is the
specifier, and the module identified by 'x' is the descendant.
ScriptModuleResolver, given a referrer and specifier, can look up the
descendant.

[kouhei (in TOK), 2017/01/17 05:26:13]

Done.

+  // might be specified as a referrer.
+  virtual void registerModuleScript(ModuleScript*) = 0;
+
+  // Implements "Runtime Semantics: HostResolveImportedModule"
+  // https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
+  virtual ScriptModule resolve(const String& specifier,

[dominicc (has gone to gerrit), 2017/01/11 03:23:47]

Maybe briefly mention this may return an empty ScriptModule if the descendant
isn't found? Is bool/ScriptModule& an even clearer interface?

[kouhei (in TOK), 2017/01/17 05:26:13]

Done.

+                               ScriptModuleIdentifier referrer) = 0;
+};
+
+}  // namespace blink
+
+#endif  // ScriptModuleResolver_h