Mojo JS: Attempt to simplify bindTo* related code.

chrome/browser/resources/plugins.js

Index: chrome/browser/resources/plugins.js
diff --git a/chrome/browser/resources/plugins.js b/chrome/browser/resources/plugins.js
index 19b21195729468df0efb39fc1a3728846e35bae2..9c3dfdcca5518adabf7d515814d8b60cbd3c90f2 100644
--- a/chrome/browser/resources/plugins.js
+++ b/chrome/browser/resources/plugins.js
@@ -263,14 +263,11 @@ function importModules(moduleNames) {
   });
 }
 
-// NOTE: Need to keep a reference to the stub here such that it is not garbage
-// collected, which causes the pipe to close and future calls from C++ to JS to
-// get dropped.
-var pluginsPageStub = null;
-
-var browserProxy = null;
-// Exposed globally such that the tests can make direct calls on it.
+// NOTE: Need to keep a global reference to the |pageProxy| such that it is not
+// garbage collected, which causes the pipe to close and future calls from C++
+// to JS to get dropped. This also allows tests to make direct calls on it.
 var pageProxy = null;
+var browserProxy = null;
 
 function initializeProxies() {
   return importModules([
@@ -290,20 +287,23 @@ function initializeProxies() {
         serviceProvider.connectToService(pluginsMojom.PluginsPageHandler.name),
         pluginsMojom.PluginsPageHandler);
 
-    // Connect pipe handle to JS code.
-    var pipe = core.createMessagePipe();
-    pluginsPageStub = connection.bindHandleToStub(
-        pipe.handle0, pluginsMojom.PluginsPage);
+    /** @constructor */
+    var PluginsPageProxy = function() {};
 
-    pageProxy = {
+    PluginsPageProxy.prototype = {
       __proto__: pluginsMojom.PluginsPage.stubClass.prototype,
+
+      /** @override */
       onPluginsUpdated: function(plugins) {
         returnPluginsData({plugins: plugins});
       },
     };
+    pageProxy = new PluginsPageProxy();
 
-    bindings.StubBindings(pluginsPageStub).delegate = pageProxy;
-    // Send pipe handle to C++.
+    var pipe = core.createMessagePipe();
+    // Connect one end of the pipe to JS.
+    connection.bindHandleToObj(pipe.handle0, pageProxy);

[yzshen1, 2016/05/27 16:24:45]

Does it make sense to name it bindHandleToImpl()?
Impl indicates that this is the implementation side of an interface. Obj seems a
little vague.

PluginsPageProxy should probably be named PluginsPageImpl. "Proxy" usually used
for the caller side of an interface.

[dpapad, 2016/05/27 17:55:37]

I found a way to simplify even more by completely hiding the pipe creation, and
simply exposing (returning) the end of the pipe that needs to be sent to C++.
This makes the client code simpler
1) No need to create message pipe.
2) New method only receives one parameter, the implementation object.
3) Client code no longer needs to depend directly on the Mojo "core" module, it
was only needed to call core.createMessagePipe.

Regarding the naming "pageProxy" I prefer to keep it as-is for two reasons.
1) Even though the "pageProxy" object is not residing on the caller side, it
still acts as a proxy since it is an intermediate to execute methods on the page
(see how PluginsPageProxy#onPluginsUpdated calls  returnPluginsData). In other
words, I am considering "returnPluginsData" (and all other global methods in
plugins.js) as the real implementation, and |pageProxy| as an intermediate
object.

2) From the test's point of view, which simulates incoming calls from the
browser, pageProxy matches exactly your expectation (caller side of an
interface), see
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/test/data/w....

[yzshen1, 2016/05/27 18:32:46]

Okay. I am fine with any name that seems appropriate to the domain experts like
you. :) Just saying that it feel counter-intuitive to me since "Proxy" has a
specific meaning in the JS bindings.

[dpapad, 2016/05/27 20:36:56]

Ended up renaming to PluginsPageImpl per your suggestion, to be more consistent
with the usage of the "term" proxy withing JS bindings terminology
(bindings.js).

+    // Send the other end of the pipe to C++.
     browserProxy.setClientPage(pipe.handle1);
   });
 }