object-ify gmmain.cpp (no functional change) to ease planned changes later

object-ify gmmain.cpp (no functional change) to ease planned changes later
Committed: https://code.google.com/p/skia/source/detail?r=6147

[epoger, 2012-10-26 16:17:06]

The diff looks much worse than it really is.  All I did was:

1. pull most of the functions into a new GMMain class
2. moved a few toplevel constants/enums because they needed to be defined
OUTSIDE of the GMMain class
3. re-indented and re-wrapped lines

The whole point of this is so that I can add a member variable to GMMain that
will slightly modify the behavior of make_name(), rather than passing a new
parameter to that function, which would require its caller to pass through the
new parameter, etc.

[DerekS, 2012-10-26 17:02:36]

On 2012/10/26 16:17:06, epoger wrote:
> The diff looks much worse than it really is.  All I did was:
> 
> 1. pull most of the functions into a new GMMain class
> 2. moved a few toplevel constants/enums because they needed to be defined
> OUTSIDE of the GMMain class
> 3. re-indented and re-wrapped lines
> 
> The whole point of this is so that I can add a member variable to GMMain that
> will slightly modify the behavior of make_name(), rather than passing a new
> parameter to that function, which would require its caller to pass through the
> new parameter, etc.

I'm not sure this CL does anything, but change the namespace of the static
functions. Is the new variable going to be static as well?

[epoger, 2012-10-26 18:12:20]

On Fri, Oct 26, 2012 at 1:02 PM, <djsollen@google.com> wrote:

> On 2012/10/26 16:17:06, epoger wrote:
>
>> The diff looks much worse than it really is.  All I did was:
>>
>
>  1. pull most of the functions into a new GMMain class
>> 2. moved a few toplevel constants/enums because they needed to be
>>
> defined
>
>> OUTSIDE of the GMMain class
>> 3. re-indented and re-wrapped lines
>>
>
>  The whole point of this is so that I can add a member variable to
>>
> GMMain that
>
>> will slightly modify the behavior of make_name(), rather than passing
>>
> a new
>
>> parameter to that function, which would require its caller to pass
>>
> through the
>
>> new parameter, etc.
>>
>
> I'm not sure this CL does anything, but change the namespace of the
> static functions. Is the new variable going to be static as well?
>

Indeed, my intention was to make this CL change as little as possible, and
to just contain the visual rearrangement that would have obscured my next
CL otherwise.

I plan on making the new variable non-static (which will require me to make
many of the functions non-static as well).


>
https://codereview.appspot.**com/6801043/<https://codereview.appspot.com/6801...
>

[DerekS, 2012-10-26 18:55:15]

lgtm.  I like the concept of the change, but its going to take many more cleaup
CL's like the one your proposing clean this thing up. :)

[tfarina1, 2012-10-29 19:52:05]

https://codereview.appspot.com/6801043/diff/1/gm/gmmain.cpp
File gm/gmmain.cpp (right):

https://codereview.appspot.com/6801043/diff/1/gm/gmmain.cpp#newcode110
gm/gmmain.cpp:110: kRaster_Backend,
nit: indent 4 spaces?

https://codereview.appspot.com/6801043/diff/1/gm/gmmain.cpp#newcode1056
gm/gmmain.cpp:1056: {
I guess this { should be in the end of the previous line :/