Add mojo::Binding<Interface> for more flexible pipe<->impl binding

mojo/services/public/cpp/view_manager/lib/view_manager_client_factory.cc

Index: mojo/services/public/cpp/view_manager/lib/view_manager_client_factory.cc
diff --git a/mojo/services/public/cpp/view_manager/lib/view_manager_client_factory.cc b/mojo/services/public/cpp/view_manager/lib/view_manager_client_factory.cc
index 91bc26571c44f8dc9cd8c8f63131b254d6193c91..b649188f529c7315ff2e8459b1ffd0d2c7969be9 100644
--- a/mojo/services/public/cpp/view_manager/lib/view_manager_client_factory.cc
+++ b/mojo/services/public/cpp/view_manager/lib/view_manager_client_factory.cc
@@ -34,7 +34,9 @@ ViewManagerClientFactory::WeakBindViewManagerToPipe(
 void ViewManagerClientFactory::Create(
     ApplicationConnection* connection,
     InterfaceRequest<ViewManagerClient> request) {
-  BindToRequest(new ViewManagerClientImpl(delegate_, shell_), &request);
+  ViewManagerClientImpl* impl =
+      BindToRequest(new ViewManagerClientImpl(delegate_, shell_), &request);
+  impl->OnConnectionEstablished();

[DaveMoore, 2014/11/11 17:18:45]

Unfortunate that this now has to be done manually. Seems prone to error.

[jamesr, 2014/11/11 17:47:49]

This is due to the unfortunate fact that BindToRequest() is a free function and
so instead of the class binding itself (which would make more sense) the binding
happens separately and after the construction of the object.  If we transition
ViewManagerClientImpl away from inheriting from InterfaceImpl<> then we can get
rid of this indirection completely.  The constructor for ViewManagerClientImpl
could take care of binding (since we never want to create one without binding it
to something) and then take care of whatever else it wanted to do in order to be
fully functional.

[jamesr, 2014/11/11 18:06:05]

See https://codereview.chromium.org/713313002.  The constructor initializes
service_ (which is all OnConnectionEstablished was doing) so the rest of the
class has one fewer state to worry about.

 }
 
 }  // namespace mojo