Factor stuff from ApplicationImpl out to a new class, ApplicationImplBase.

Factor stuff from ApplicationImpl out to a new class, ApplicationImplBase.

ApplicationImpl is now a rather dumb class that just calls its
ApplicationDelegate.

Using base/implementation classes is preferable to the delegate pattern
because:
* It's simpler (see below).
* With the delgate pattern, the impl and the delegate both need pointers
  to each other. And so there are lifetime problems/considerations.
* The delegate just ends up calling into the impl a lot.

Unfortunately, it's rather hard (impossible) to use ApplicationImplBase
right now (as intended): I'll need to refactor
ApplicationRunner(Chromium) to not just instantiate ApplicationImpl,
etc.

(I'll also need a story for the crazy that is
ApplicationImpl(Base)::Terminate().)

R=vardhan@google.com

Committed: https://chromium.googlesource.com/external/mojo/+/0a68a8d847fc6f6fd3c494992c4ab6bd60bddcb6

[viettrungluu, 2016-05-17 22:31:15]

Depends on https://codereview.chromium.org/1990603002/.

[viettrungluu, 2016-05-17 22:34:04]

On 2016/05/17 22:31:15, viettrungluu wrote:
> Depends on https://codereview.chromium.org/1990603002/.

D'oh, must fix android.

Also, I guess the commit message/CL description should also discuss why this is
preferable to ApplicationDelegate. Will update....

[viettrungluu, 2016-05-17 22:35:55]

Description was changed from

==========
Factor stuff from ApplicationImpl out to a new class, ApplicationImplBase.

ApplicationImpl is now a rather dumb class that just calls its
ApplicationDelegate.

Unfortunately, it's rather hard (impossible) to use ApplicationImplBase
right now (as intended): I'll need to refactor
ApplicationRunner(Chromium) to not just instantiate ApplicationImpl,
etc.

(I'll also need a story for the crazy that is
ApplicationImpl(Base)::Terminate().)

R=vardhan@google.com
==========

to

==========
Factor stuff from ApplicationImpl out to a new class, ApplicationImplBase.

ApplicationImpl is now a rather dumb class that just calls its
ApplicationDelegate.

Using base/implementation classes is preferable to the delegate pattern
because:
* It's simpler (see below).
* With the delgate pattern, the impl and the delegate both need pointers
  to each other. And so there are lifetime problems/considerations.
* The delegate just ends up calling into the impl a lot.

Unfortunately, it's rather hard (impossible) to use ApplicationImplBase
right now (as intended): I'll need to refactor
ApplicationRunner(Chromium) to not just instantiate ApplicationImpl,
etc.

(I'll also need a story for the crazy that is
ApplicationImpl(Base)::Terminate().)

R=vardhan@google.com
==========

[vardhan, 2016-05-17 23:36:53]

lgtm

https://codereview.chromium.org/1985223003/diff/20001/mojo/public/cpp/applica...
File mojo/public/cpp/application/lib/application_runner.cc (right):

https://codereview.chromium.org/1985223003/diff/20001/mojo/public/cpp/applica...
mojo/public/cpp/application/lib/application_runner.cc:20: void
ApplicationImplBase::Terminate() {
feels weird that this is defined here.  is there a better way?

(i'm assuming we define it here because it uses ApplicationRunner's "managed"
RunLoop?)

[viettrungluu, 2016-05-17 23:42:50]

https://codereview.chromium.org/1985223003/diff/20001/mojo/public/cpp/applica...
File mojo/public/cpp/application/lib/application_runner.cc (right):

https://codereview.chromium.org/1985223003/diff/20001/mojo/public/cpp/applica...
mojo/public/cpp/application/lib/application_runner.cc:20: void
ApplicationImplBase::Terminate() {
On 2016/05/17 23:36:52, vardhan wrote:
> feels weird that this is defined here.  is there a better way?

Yeah, but it'll require a bunch of work.

> 
> (i'm assuming we define it here because it uses ApplicationRunner's "managed"
> RunLoop?)

[viettrungluu, 2016-05-17 23:43:19]

Description was changed from

==========
Factor stuff from ApplicationImpl out to a new class, ApplicationImplBase.

ApplicationImpl is now a rather dumb class that just calls its
ApplicationDelegate.

Using base/implementation classes is preferable to the delegate pattern
because:
* It's simpler (see below).
* With the delgate pattern, the impl and the delegate both need pointers
  to each other. And so there are lifetime problems/considerations.
* The delegate just ends up calling into the impl a lot.

Unfortunately, it's rather hard (impossible) to use ApplicationImplBase
right now (as intended): I'll need to refactor
ApplicationRunner(Chromium) to not just instantiate ApplicationImpl,
etc.

(I'll also need a story for the crazy that is
ApplicationImpl(Base)::Terminate().)

R=vardhan@google.com
==========

to

==========
Factor stuff from ApplicationImpl out to a new class, ApplicationImplBase.

ApplicationImpl is now a rather dumb class that just calls its
ApplicationDelegate.

Using base/implementation classes is preferable to the delegate pattern
because:
* It's simpler (see below).
* With the delgate pattern, the impl and the delegate both need pointers
  to each other. And so there are lifetime problems/considerations.
* The delegate just ends up calling into the impl a lot.

Unfortunately, it's rather hard (impossible) to use ApplicationImplBase
right now (as intended): I'll need to refactor
ApplicationRunner(Chromium) to not just instantiate ApplicationImpl,
etc.

(I'll also need a story for the crazy that is
ApplicationImpl(Base)::Terminate().)

R=vardhan@google.com

Committed:
https://chromium.googlesource.com/external/mojo/+/0a68a8d847fc6f6fd3c494992c4...
==========

[viettrungluu, 2016-05-17 23:43:21]

Committed patchset #2 (id:20001) manually as
0a68a8d847fc6f6fd3c494992c4ab6bd60bddcb6 (presubmit successful).