net::AddressList no longer privately inherits from std::vector

net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

This "conservative" approach, with employing composition instead of
inheritance and delegating method calls was suggested by Nico Weber and
indeed that meant not having to change anything but the header.

Committed: https://crrev.com/74eaaac1d94b0151b70aac90e34d48c74f7d6e11
Cr-Commit-Position: refs/heads/master@{#395605}

[mpawlowski, 2016-05-23 09:59:50]

Description was changed from

==========
net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

BUG=
==========

to

==========
net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

This "conservative" approach, with employing composition instead of inheritance
and delegating method calls was suggested by Nico Weber and indeed that meant
not having to change anything but the header.
==========

[mpawlowski, 2016-05-23 09:59:50]

mpawlowski@opera.com changed reviewers:
+ avi@chromium.org, mmenke@chromium.org, thakis@chromium.org

[mpawlowski, 2016-05-23 10:00:28]

Description was changed from

==========
net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

This "conservative" approach, with employing composition instead of inheritance
and delegating method calls was suggested by Nico Weber and indeed that meant
not having to change anything but the header.
==========

to

==========
net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

This "conservative" approach, with employing composition instead of 
inheritance and delegating method calls was suggested by Nico Weber and 
indeed that meant not having to change anything but the header.
==========

[Nico, 2016-05-23 14:05:46]

lgtm

[Nico, 2016-05-23 14:06:13]

The CQ bit was checked by thakis@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-05-23 14:06:23]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2003973002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2003973002/1

[commit-bot: I haz the power, 2016-05-23 14:15:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-23 14:15:12]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[Nico, 2016-05-23 14:16:04]

looks like cast needs a const overload of insert()

[mmenke, 2016-05-23 15:03:44]

On 2016/05/23 14:16:04, Nico wrote:
> looks like cast needs a const overload of insert()

Just glancing at it, seems reasonable.  Please ping me again when you get things
working.

[mpawlowski, 2016-05-23 15:15:16]

The CQ bit was checked by mpawlowski@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-05-23 15:15:26]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2003973002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/2003973002/20001

[commit-bot: I haz the power, 2016-05-23 15:23:35]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-23 15:23:36]

Dry run: Try jobs failed on following builders:
  ios-simulator-gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-gn/...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Avi (use Gerrit), 2016-05-23 15:29:21]

LGTM, but you have the review covered by the owners so that's all I'll say.

Thanks for doing this.

[mpawlowski, 2016-05-24 08:40:11]

The CQ bit was checked by mpawlowski@opera.com to run a CQ dry run

[mpawlowski, 2016-05-24 08:40:26]

The CQ bit was unchecked by mpawlowski@opera.com

[mpawlowski, 2016-05-24 08:40:32]

The CQ bit was checked by mpawlowski@opera.com

[mpawlowski, 2016-05-24 08:40:32]

The patchset sent to the CQ was uploaded after l-g-t-m from thakis@chromium.org,
avi@chromium.org
Link to the patchset: https://codereview.chromium.org/2003973002/#ps40001
(title: " ")

[commit-bot: I haz the power, 2016-05-24 08:40:50]

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

[commit-bot: I haz the power, 2016-05-24 08:46:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-24 08:46:59]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[mmenke, 2016-05-24 14:45:59]

LGTM (That windows failure is unrelated to this CL)

[mpawlowski, 2016-05-24 14:46:58]

The CQ bit was checked by mpawlowski@opera.com

[commit-bot: I haz the power, 2016-05-24 14:47:07]

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

[commit-bot: I haz the power, 2016-05-24 15:45:49]

Description was changed from

==========
net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

This "conservative" approach, with employing composition instead of 
inheritance and delegating method calls was suggested by Nico Weber and 
indeed that meant not having to change anything but the header.
==========

to

==========
net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

This "conservative" approach, with employing composition instead of 
inheritance and delegating method calls was suggested by Nico Weber and 
indeed that meant not having to change anything but the header.
==========

[commit-bot: I haz the power, 2016-05-24 15:45:50]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-05-24 15:47:04]

Description was changed from

==========
net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

This "conservative" approach, with employing composition instead of 
inheritance and delegating method calls was suggested by Nico Weber and 
indeed that meant not having to change anything but the header.
==========

to

==========
net::AddressList no longer privately inherits from std::vector

The private inheritance was not only against the style guide, it also
forbade anyone from using a standalone std::vector<net::IPEndPoint>,
since the manually defined AddressList ctor/dtor conflicted with
automatically generated ones for vector<T> instantiation.

This should be considered a first step of refactoring that class.
AddressList is neither a list, nor does it store addresses,
it's a vector of endpoints, so the name is misleading. It
should be changed.

The canonical_name_ member is only currently used in
PepperHostResolverMessageFilter, it's probably not the best idea to keep
it around in a generic class like this. Grepping AddressList reveals 500+
instances in the codeebase, and ony one use of canonical_name() outside
of unit tests. Perhaps a pair<AddressList, string> should be used for
that one particular use-case and a bare AddressList without that extra
member should be used everywhere else.

This "conservative" approach, with employing composition instead of
inheritance and delegating method calls was suggested by Nico Weber and
indeed that meant not having to change anything but the header.

Committed: https://crrev.com/74eaaac1d94b0151b70aac90e34d48c74f7d6e11
Cr-Commit-Position: refs/heads/master@{#395605}
==========

[commit-bot: I haz the power, 2016-05-24 15:47:05]

Patchset 3 (id:??) landed as
https://crrev.com/74eaaac1d94b0151b70aac90e34d48c74f7d6e11
Cr-Commit-Position: refs/heads/master@{#395605}