Add an Implementations class

Add an Implementations class

This class provides a static create() method that allows client code to
generate a class appropriate to the running build.  This is superior to
the current approach, which requires a ChromeApplication, which may not
always be available.

To use this create() method, one needs to:
- give the upstream class a public parameterless constructor,
- give the downstream class a public parameterless constructor,
- register the downstream class in the downstream Implementations
  getClass() method, and
- invoke this method on the appropriate class
  (e.g., Implementations.create(MyType.class)).

In order to pull this off, an ImplementationsMetadata is built into the
package depending on whether or not the downstream should be
responsible for constructing the Implementations instance.

BUG=685383

[cco3, 2017-02-06 19:16:17]

cco3@chromium.org changed reviewers:
+ mariakhomenko@chromium.org

[cco3, 2017-02-06 19:16:18]

Hi Maria.  I decided to practice some dark art with the build system to pull
this off and address aberent@'s concerns.  Let me know if this is anywhere near
remotely acceptable.

[Maria, 2017-02-06 20:19:34]

On 2017/02/06 19:16:18, cco3 wrote:
> Hi Maria.  I decided to practice some dark art with the build system to pull
> this off and address aberent@'s concerns.  Let me know if this is anywhere
near
> remotely acceptable.

I am concerned about the complexity we introduce in this change -- it's a lot
harder to understand what's happening here and how it works and we are saving
the work of creating two straightforward methods for a developer. I am not
entirely convinced this is better -- perhaps you can explain the motivation to
me?

[cco3, 2017-02-06 21:27:14]

On 2017/02/06 20:19:34, Maria wrote:
> On 2017/02/06 19:16:18, cco3 wrote:
> > Hi Maria.  I decided to practice some dark art with the build system to pull
> > this off and address aberent@'s concerns.  Let me know if this is anywhere
> near
> > remotely acceptable.
> 
> I am concerned about the complexity we introduce in this change -- it's a lot
> harder to understand what's happening here and how it works and we are saving
> the work of creating two straightforward methods for a developer. I am not
> entirely convinced this is better -- perhaps you can explain the motivation to
> me?

1. We can save all that work and not introduce any more complexity by taking the
same route I took before, but instead making it a non-static method (so that the
client code has to have an instance of ChromeApplication).

2. The justification for this approach (and I'm not necessarily claiming it's
better) is that it gets us all those benefits with the added benefits of easier
invocation (static) and safer invocation (not relying on an existing
ChromeApplication).  A lot of client code is already downcasting the
ApplicationContext, and as aberent said, there are some times you would want to
get a downstream specific implementation and there is no ApplicationContext
available at all.  Giving the upstream component some direct hook into the
downstream classes like we are doing here is the only way to get around the fact
that we may not have an ApplicationContext.

[cco3, 2017-02-06 21:27:33]

Adding aberent@,

[aberent, 2017-02-07 10:36:30]

On 2017/02/06 21:27:33, cco3 wrote:
> Adding aberent@,

I think this resolves my original concerns. Given the complexity of this, I do,
however, wonder whether it would be better to do nothing (i.e. to leave the code
as it was before https://codereview.chromium.org/2652383002/ and
https://codereview.chromium.org/2657053002).

It would be easier to see if this really is justified if this and the equivalent
of https://codereview.chromium.org/2652383002/ were combined into a single CL.

Once again, if you do decide to go ahead with this, please test it with
downstream builds before landing it (these are not tested on the upstream
trybots).

[cco3, 2017-02-07 18:23:37]

Note that I could also accomplish this by attempting to load a downstream class
at build time (by its specific downstream name).  This would remove build
trickery.  I'll upload a patchset with that approach and you all can tell me if
it's still to complicated.

[cco3, 2017-02-07 19:35:56]

On 2017/02/07 18:23:37, cco3 wrote:
> Note that I could also accomplish this by attempting to load a downstream
class
> at build time (by its specific downstream name).  This would remove build
> trickery.  I'll upload a patchset with that approach and you all can tell me
if
> it's still to complicated.

Alright, here's a simpler approach.

[Maria, 2017-02-10 19:57:32]

On 2017/02/07 19:35:56, cco3 wrote:
> On 2017/02/07 18:23:37, cco3 wrote:
> > Note that I could also accomplish this by attempting to load a downstream
> class
> > at build time (by its specific downstream name).  This would remove build
> > trickery.  I'll upload a patchset with that approach and you all can tell me
> if
> > it's still to complicated.
> 
> Alright, here's a simpler approach.

So, here's how I am thinking about this:

Pros:
 - Fewer methods on ChromeApplication/ChromeApplicationInternal classes
 - Removes ChromeApplication casting from a bunch of callers

Cons:
 - A fair bit harder to understand how the mechanism works
 - Slower (reflection is slow and try/catch is also slow)

- Not quite sure where this falls in LOC added/removed. Probably pretty close,
given that the new impl is 100+ lines (upstream + downstream).

Right now I am not 100% convinced pros outweigh the cons. Maybe I am not
thinking about some advantages of this approach that you see?

[cco3, 2017-02-27 19:28:15]

Description was changed from

==========
Add an Implementations class

This class provides a static create() method that allows client code to
generate a class appropriate to the running build.  This is superior to
the current approach, which requires a ChromeApplication, which may not
always be available.

To use this create() method, one needs to:
- give the upstream class a public parameterless constructor,
- give the downstream class a public parameterless constructor,
- register the downstream class in the downstream Implementations
  getClass() method, and
- invoke this method on the appropriate class
  (e.g., Implementations.create(MyType.class)).

In order to pull this off, an ImplementationsMetadata is built into the
package depending on whether or not the downstream should be
responsible for constructing the Implementations instance.

BUG=685383
==========

to

==========
Add an Implementations class

This class provides a static create() method that allows client code to
generate a class appropriate to the running build.  This is superior to
the current approach, which requires a ChromeApplication, which may not
always be available.

To use this create() method, one needs to:
- give the upstream class a public parameterless constructor,
- give the downstream class a public parameterless constructor,
- register the downstream class in the downstream Implementations
  getClass() method, and
- invoke this method on the appropriate class
  (e.g., Implementations.create(MyType.class)).

In order to pull this off, an ImplementationsMetadata is built into the
package depending on whether or not the downstream should be
responsible for constructing the Implementations instance.

BUG=685383
==========