Create base class for TabHelpers.

Create base class for TabHelpers.

BUG=107201
TEST=none


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=153571

Reverted: http://src.chromium.org/viewvc/chrome?view=rev&revision=153591

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=153807

[jam, 2012-08-27 21:34:26]

lgtm

[commit-bot: I haz the power, 2012-08-27 21:37:26]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/avi@chromium.org/10868115/2001

[commit-bot: I haz the power, 2012-08-27 23:06:06]

Change committed as 153571

[Avi (use Gerrit), 2012-08-28 20:44:09]

Try again. This time it works in Visual Studio, though it's not as pretty.

[jam, 2012-08-28 21:47:37]

lgtm

[commit-bot: I haz the power, 2012-08-28 21:56:23]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/avi@chromium.org/10868115/14005

[commit-bot: I haz the power, 2012-08-29 00:19:47]

Change committed as 153807

[sky, 2012-09-12 00:03:13]

https://chromiumcodereview.appspot.com/10868115/diff/14005/chrome/browser/tab...
File chrome/browser/tab_contents/web_contents_user_data.h (right):

https://chromiumcodereview.appspot.com/10868115/diff/14005/chrome/browser/tab...
chrome/browser/tab_contents/web_contents_user_data.h:19: //   static int
kUserDataKey;
If this isn't constant, shouldn't it be named user_data_key and with the rest of
the fields? Where is it expected this will be set? If it's public, might others
mutate it?

[Avi (use Gerrit), 2012-09-12 00:08:44]

Scott, you appear to misunderstand the purpose of the kUserDataKey field. I've
answered the questions you've asked, but they're the wrong questions.

https://chromiumcodereview.appspot.com/10868115/diff/14005/chrome/browser/tab...
File chrome/browser/tab_contents/web_contents_user_data.h (right):

https://chromiumcodereview.appspot.com/10868115/diff/14005/chrome/browser/tab...
chrome/browser/tab_contents/web_contents_user_data.h:19: //   static int
kUserDataKey;
On 2012/09/12 00:03:13, sky wrote:
> If this isn't constant, shouldn't it be named user_data_key and with the rest
of
> the fields?

The key to the puzzle is that its value is irrelevant; its address is constant,
and that's all that matters.

> Where is it expected this will be set?

It's not supposed to be set.

> If it's public, might others mutate it?

It doesn't matter if they do.

[sky, 2012-09-12 00:13:47]

My mistake. I see now that it's the address that matters and not the value. In
that case can it be const and before the destructor/constructor as per the style
guide?

[Avi (use Gerrit), 2012-09-12 00:15:36]

On 2012/09/12 00:13:47, sky wrote:
> In that case can it be const

No, it can't. Because then Visual Studio will fold all instances of it together
and this template will fail. (Note the title of patch set 4.)

> and before the destructor/constructor as per the style
> guide?

Would it go there even if it were not const?

[awong, 2012-09-12 00:16:19]

On 2012/09/12 00:13:47, sky wrote:
> My mistake. I see now that it's the address that matters and not the value. In
> that case can it be const and before the destructor/constructor as per the
style
> guide?

Nope...MSVC tries to be too smart and might collapse the storage for a const of
this type. This violates spec, but it is unfortunately reality.

[sky, 2012-09-12 03:38:47]

*SIGH*

[Avi (use Gerrit), 2012-09-12 03:45:44]

On 2012/09/12 03:38:47, sky wrote:
> *SIGH*

Indeed, that's how I felt after dealing with all of this. If you have any ideas
to make this more awesome, I'd be happy to make them happen. I'm all out of
them, though :(