Mojo: abstract interface implementation from generated Stub classes

Mojo: abstract interface implementation from generated Stub classes

Remove RemotePtr<S>::SetPeer method in favor of an optionally NULL second constructor argument. (The reset method also gains an optionally NULL second argument.)

R=davemoore@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=243416

[darin (slow to review), 2013-12-27 16:49:53]

This patch is a work in progress, but I wanted to get some input on the change.
There are two changes here: 1) make it so that users just have to implement a
Mojo interface rather than a Mojo interface's Stub class, and 2) "simplify"
RemotePtr to eliminate the SetPeer method, replacing it with a second
constructor argument. Thoughts? I'm on the fence about #2. I think #1 is good.

[DaveMoore, 2013-12-27 17:58:55]

I like the simplification of creating remoteptrs

https://codereview.chromium.org/109103003/diff/1/mojo/services/native_viewpor...
File mojo/services/native_viewport/native_viewport_service.cc (right):

https://codereview.chromium.org/109103003/diff/1/mojo/services/native_viewpor...
mojo/services/native_viewport/native_viewport_service.cc:28: : public
mojo::NativeViewport,
I think we're going to find ourselves with these kinds of name collisions more
with this model, and it could get confusing. For the service FooService you have
Foo and FooClient as mojom generated names. Then you have to create a service
implementation, which needs an internal class that represents a connection to a
specific client, as well as an implementation of that client. So the pattern
I've been using is

Foo: thing that there is one of, that the ServiceManager uses to vend
connections.
FooServiceImpl: Inherits from FooServiceStub. Connection to a specific client.
Foo keeps a vector of the extant ones
FooClientImpl: The client implementation. inherits from FooClientStub.

[darin (slow to review), 2014-01-07 05:32:25]

On 2013/12/27 17:58:55, DaveMoore wrote:
> I like the simplification of creating remoteptrs
> 
>
https://codereview.chromium.org/109103003/diff/1/mojo/services/native_viewpor...
> File mojo/services/native_viewport/native_viewport_service.cc (right):
> 
>
https://codereview.chromium.org/109103003/diff/1/mojo/services/native_viewpor...
> mojo/services/native_viewport/native_viewport_service.cc:28: : public
> mojo::NativeViewport,
> I think we're going to find ourselves with these kinds of name collisions more
> with this model, and it could get confusing. For the service FooService you
have
> Foo and FooClient as mojom generated names. Then you have to create a service
> implementation, which needs an internal class that represents a connection to
a
> specific client, as well as an implementation of that client. So the pattern
> I've been using is
> 
> Foo: thing that there is one of, that the ServiceManager uses to vend
> connections.
> FooServiceImpl: Inherits from FooServiceStub. Connection to a specific client.
> Foo keeps a vector of the extant ones
> FooClientImpl: The client implementation. inherits from FooClientStub.

As discussed, I'm going to explore adding some sugar for the service side in
a separate CL.

[darin (slow to review), 2014-01-07 05:45:11]

PTAL

[DaveMoore, 2014-01-07 22:01:41]

lgtm

[darin (slow to review), 2014-01-07 22:42:00]

Committed patchset #7 manually as r243416 (presubmit successful).