Unify InputMethodIMM32 into InputMethodWin again

Unify InputMethodIMM32 into InputMethodWin again

This CL logically reverts r206742 "Split InputMethodWin into InputMethodIMM32 and InputMethodTSF".
That was a tentative solution during the Aura transition.

BUG=330735, 344209
TEST=manually done on Windows 7

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

[yukawa, 2014-02-14 06:32:33]

Hi Shiino-san,
Could you take a look?  Basically this is a clean-up CL and there should be no
behavioral change.

[Yuki, 2014-02-19 05:37:13]

lgtm with a nit.

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win.h
File ui/base/ime/input_method_win.h (right):

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win...
ui/base/ime/input_method_win.h:25: private:
I think InputMethodWin is just a concrete implementation of InputMethod, and
it's not good to change the visibility.  Public methods should remain as
public:.

[yukawa, 2014-02-19 06:53:42]

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win.h
File ui/base/ime/input_method_win.h (right):

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win...
ui/base/ime/input_method_win.h:19: // A common InputMethod implementation shared
between IMM32 and TSF.
Oops, I'll update this line too.

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win...
ui/base/ime/input_method_win.h:25: private:
On 2014/02/19 05:37:13, Yuki wrote:
> I think InputMethodWin is just a concrete implementation of InputMethod, and
> it's not good to change the visibility.  Public methods should remain as
> public:.

Hmm, I sometimes use this style but I'll follow your suggestion if you dislike
this style?
Have you read this sort of articles?
http://stackoverflow.com/questions/2170688/private-virtual-method-in-c
What do you think?

[Yuki, 2014-02-19 07:13:57]

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win.h
File ui/base/ime/input_method_win.h (right):

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win...
ui/base/ime/input_method_win.h:25: private:
On 2014/02/19 06:53:43, yukawa wrote:
> On 2014/02/19 05:37:13, Yuki wrote:
> > I think InputMethodWin is just a concrete implementation of InputMethod, and
> > it's not good to change the visibility.  Public methods should remain as
> > public:.
> 
> Hmm, I sometimes use this style but I'll follow your suggestion if you dislike
> this style?
> Have you read this sort of articles?
> http://stackoverflow.com/questions/2170688/private-virtual-method-in-c
> What do you think?

Good article, but it wouldn't apply to this case.  Whether or not you made these
methods private: or not, they're public: in the most superclass InputMethod, and
they're callable.

  InputMethodWin* a = new InputMethodWin(...);
  InputMethod* b = a;
  a->IsActive();  // Invalid call because of private:
  b->IsActive();  // Okay

This difference doesn't make much sense IMHO, especially when we'd like a is-a
relationship between them.

[yukawa, 2014-02-19 10:02:42]

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win.h
File ui/base/ime/input_method_win.h (right):

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win...
ui/base/ime/input_method_win.h:19: // A common InputMethod implementation shared
between IMM32 and TSF.
On 2014/02/19 06:53:43, yukawa wrote:
> Oops, I'll update this line too.

Done.

https://codereview.chromium.org/166063002/diff/1/ui/base/ime/input_method_win...
ui/base/ime/input_method_win.h:25: private:
Done. I left public and protected as they are. Do they fit your request?

On 2014/02/19 07:13:57, Yuki wrote:
> On 2014/02/19 06:53:43, yukawa wrote:
> > On 2014/02/19 05:37:13, Yuki wrote:
> > > I think InputMethodWin is just a concrete implementation of InputMethod,
and
> > > it's not good to change the visibility.  Public methods should remain as
> > > public:.
> > 
> > Hmm, I sometimes use this style but I'll follow your suggestion if you
dislike
> > this style?
> > Have you read this sort of articles?
> > http://stackoverflow.com/questions/2170688/private-virtual-method-in-c
> > What do you think?
> 
> Good article, but it wouldn't apply to this case.  Whether or not you made
these
> methods private: or not, they're public: in the most superclass InputMethod,
and
> they're callable.
> 
>   InputMethodWin* a = new InputMethodWin(...);
>   InputMethod* b = a;
>   a->IsActive();  // Invalid call because of private:
>   b->IsActive();  // Okay
> 
> This difference doesn't make much sense IMHO, especially when we'd like a is-a
> relationship between them.

[Yuki, 2014-02-19 13:07:30]

Thanks, lgtm.

[yukawa, 2014-02-19 17:08:58]

The CQ bit was checked by yukawa@chromium.org

[commit-bot: I haz the power, 2014-02-19 17:12:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/yukawa@chromium.org/166063002/170001

[commit-bot: I haz the power, 2014-02-19 22:10:41]

Change committed as 252112