IDL: Avoid global variables in compute_interfaces_info_individual.py

IDL: Avoid global variables in compute_interfaces_info_individual.py

compute_interfaces_info_individual has global variables. These variables
are updated each time we call compute_info_individual(). This could be
a problem when we want to call compute_info_individual() for separate
components in the same process. Such cases could happen in
run-bindings-test when we add union types collection in
compute_info_individual(). We would want to collect all union types
which are used by IDL files under Source/bindings/test/idls, but we
don't want to collect them for IDL files under Source/{core,modules}.
This CL introduces a class and moves global variables into the class
as instance variables.

This CL doesn't change generated bindings code at this moment.

BUG=425916
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=184314

[bashi, 2014-10-22 09:28:11]

Patchset #1 (id:1) has been deleted

[bashi, 2014-10-22 09:43:30]

bashi@chromium.org changed reviewers:
+ haraken@chromium.org, tasak@google.com

[bashi, 2014-10-22 09:43:30]

PTAL?

https://codereview.chromium.org/671863002/diff/20001/Tools/Scripts/webkitpy/b...
File Tools/Scripts/webkitpy/bindings/main.py (right):

https://codereview.chromium.org/671863002/diff/20001/Tools/Scripts/webkitpy/b...
Tools/Scripts/webkitpy/bindings/main.py:153:
info_individuals.append(info_generator_individual.get_info_as_dict())
No actual change here in this CL, but I'm planning to add logic something like:
- collect union types for IDL files under Source/bindings/tests/idls
- don't collect union types for IDL files under Source/core and Source/bindings

We will create container classes for all collected union types, so if we collect
union types for core/modules IDL files, the expectation of run-bindings-tests
could be affected by them. I don't think it's desirable.

[Jens Widell, 2014-10-22 10:10:25]

jl@opera.com changed reviewers:
+ jl@opera.com

[Jens Widell, 2014-10-22 10:10:26]

The refactoring LGTM.

https://codereview.chromium.org/671863002/diff/20001/Source/bindings/scripts/...
File Source/bindings/scripts/compute_interfaces_info_individual.py (right):

https://codereview.chromium.org/671863002/diff/20001/Source/bindings/scripts/...
Source/bindings/scripts/compute_interfaces_info_individual.py:131: class
InterfaceInfoGeneratorIndividual(object):
"Invididual" here (in various names) is the opposite of "overall" (I guess), and
doesn't necessarily need to be repeated quite as much. It doesn't add anything
of value to this class name, I think.

And "Generator" sounds a bit odd to me. This class really generate anything, it
collects (or "computes".)

So maybe InterfaceInfoCollector? Or *Computer, although that sounds a bit
strange to me. Maybe *Computer with compute_info(), or *Collector with
collect_info()/collect_info_from().

Ah, I don't know. Naming things is always the hardest part. :-)

[haraken, 2014-10-22 11:58:52]

LGTM

https://codereview.chromium.org/671863002/diff/20001/Source/bindings/scripts/...
File Source/bindings/scripts/compute_interfaces_info_individual.py (right):

https://codereview.chromium.org/671863002/diff/20001/Source/bindings/scripts/...
Source/bindings/scripts/compute_interfaces_info_individual.py:131: class
InterfaceInfoGeneratorIndividual(object):
On 2014/10/22 10:10:26, Jens Widell wrote:
> "Invididual" here (in various names) is the opposite of "overall" (I guess),
and
> doesn't necessarily need to be repeated quite as much. It doesn't add anything
> of value to this class name, I think.
> 
> And "Generator" sounds a bit odd to me. This class really generate anything,
it
> collects (or "computes".)
> 
> So maybe InterfaceInfoCollector? Or *Computer, although that sounds a bit
> strange to me. Maybe *Computer with compute_info(), or *Collector with
> collect_info()/collect_info_from().
> 
> Ah, I don't know. Naming things is always the hardest part. :-)

+1 to Collector :)

[bashi, 2014-10-23 22:55:13]

Thank you for reviews! I'm going to land this.

https://codereview.chromium.org/671863002/diff/20001/Source/bindings/scripts/...
File Source/bindings/scripts/compute_interfaces_info_individual.py (right):

https://codereview.chromium.org/671863002/diff/20001/Source/bindings/scripts/...
Source/bindings/scripts/compute_interfaces_info_individual.py:131: class
InterfaceInfoGeneratorIndividual(object):
On 2014/10/22 11:58:52, haraken wrote:
> On 2014/10/22 10:10:26, Jens Widell wrote:
> > "Invididual" here (in various names) is the opposite of "overall" (I guess),
> and
> > doesn't necessarily need to be repeated quite as much. It doesn't add
anything
> > of value to this class name, I think.
> > 
> > And "Generator" sounds a bit odd to me. This class really generate anything,
> it
> > collects (or "computes".)
> > 
> > So maybe InterfaceInfoCollector? Or *Computer, although that sounds a bit
> > strange to me. Maybe *Computer with compute_info(), or *Collector with
> > collect_info()/collect_info_from().
> > 
> > Ah, I don't know. Naming things is always the hardest part. :-)
> 
> +1 to Collector :)

Done. I couldn't come up with a good name for this class...

[bashi, 2014-10-23 22:56:22]

The CQ bit was checked by bashi@chromium.org

[commit-bot: I haz the power, 2014-10-23 22:58:01]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/671863002/40001

[bashi, 2014-10-23 23:02:25]

The CQ bit was unchecked by bashi@chromium.org

[bashi, 2014-10-23 23:06:22]

The CQ bit was checked by bashi@chromium.org

[commit-bot: I haz the power, 2014-10-23 23:06:56]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/671863002/60001

[commit-bot: I haz the power, 2014-10-24 00:09:47]

Committed patchset #3 (id:60001) as 184314