Extract PrefServiceBase into chrome/browser/api. Use in api and autofill.

Extract PrefServiceBase into chrome/browser/api.  Use in api and autofill.

TBR=owners other than for prefs and api, since other changes are trivial and mechanical
BUG=140037
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=152569

[Jói, 2012-08-16 14:26:02]

mnissler: prefs OWNER, please review with a focus on the API that I extracted. 
Can focus on changes in chrome/browser/prefs and chrome/browser/api/prefs.

erikwright: Reviewer for all files.

We already had a big discussion about whether to split the interface as per the
TODOs now in pref_service_base.h.  We could do this now, or as a follow-up; for
me it's easier as a follow-up and I also think it gives some time for design
discussions.

The discussion so far is captured at http://codereview.chromium.org/10857031/

Cheers,
Jói

[erikwright (departed), 2012-08-16 15:12:40]

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
File chrome/browser/api/prefs/pref_service_base.h (right):

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
chrome/browser/api/prefs/pref_service_base.h:35: // Retrieves a PrefServiceBase
for the given profile.
I'm not a big fan of this. Is there a reason why Profile::GetPrefs can't return
a PrefServiceBase?

Presumably in the long term it won't be necessary. Perhaps in the meantime we
could add Profile::GetPrefServiceBase?

http://codereview.chromium.org/10828345/diff/1/chrome/browser/prefs/pref_serv...
File chrome/browser/prefs/pref_service.h (right):

http://codereview.chromium.org/10828345/diff/1/chrome/browser/prefs/pref_serv...
chrome/browser/prefs/pref_service.h:32: class NotificationObserver;
I think this can be removed since it is part of the implemented API, thus not
considered transitive.

[Mattias Nissler (ping if slow), 2012-08-16 15:16:42]

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
File chrome/browser/api/prefs/pref_member.cc (right):

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
chrome/browser/api/prefs/pref_member.cc:38:
DCHECK(prefs_->GetUserPrefValue(pref_name_.c_str()))
Wait, what's this? This is incorrect.

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
chrome/browser/api/prefs/pref_member.cc:75:
prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
also incorrect

[Jói, 2012-08-16 15:34:17]

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
File chrome/browser/api/prefs/pref_member.cc (right):

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
chrome/browser/api/prefs/pref_member.cc:38:
DCHECK(prefs_->GetUserPrefValue(pref_name_.c_str()))
On 2012/08/16 15:16:42, Mattias Nissler wrote:
> Wait, what's this? This is incorrect.

See below.

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
chrome/browser/api/prefs/pref_member.cc:75:
prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
On 2012/08/16 15:16:42, Mattias Nissler wrote:
> also incorrect

This, and the thing above, was me trying to get rid of FindPreference from the
base API.  I misread the GetUserPrefValue documentation, and I see now that this
is not equivalent.

I wonder if I should instead simply add GetPrefValue(name) which returns a
base::Value* like these two guys, but basically just does
FindPreference(name)->GetValue().  I think that would make both places
equivalent, although the DCHECK at the top would be checking a different thing
it should be semantically the same?

[Jói, 2012-08-16 15:35:56]

Will wait to upload a new patch until I hear back from Mattias and implement
whatever solution we come up with for the FindPreference issue in pref_value.cc

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
File chrome/browser/api/prefs/pref_service_base.h (right):

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
chrome/browser/api/prefs/pref_service_base.h:35: // Retrieves a PrefServiceBase
for the given profile.
On 2012/08/16 15:12:40, erikwright wrote:
> I'm not a big fan of this. Is there a reason why Profile::GetPrefs can't
return
> a PrefServiceBase?
> 
> Presumably in the long term it won't be necessary. Perhaps in the meantime we
> could add Profile::GetPrefServiceBase?

First off I should note that we want to stop depending on Profile.

I actually think this is a good pattern as it makes the implementation more
independent of the interfaces.  More and more I've been thinking we should
introduce a ProfileHandle, TabHandle, and perhaps other XyzHandle base classes
for things like Profile, TabContents, etc. that we don't want Browser Components
to depend on but which lots of services hang off of.  Then we can have ForXyz
static methods that are fulfilled at link time to retrieve the current browser's
implementation of these, and break the dependency on the concrete implementation
and the details of its structure, except for the fact that you can get e.g. a
PrefServiceBase from a Profile.

In content, we have at least a couple of examples of static methods named
ForXyz, and we have several named FromXyz.  The latter are used for methods that
cast from one type to another, so I think ForXyz is the most appropriate
convention.

I'm happy to discuss, but I think the alternative is to end up with huge big
interfaces (say ProfileAPI or ProfileBase) that mirror most of the stuff from
these big objects like Profile and TabContents, and importantly, may have
significant per-platform differences.

This approach also takes a cue from the ProfileKeyedService approach that has
been used with great success to reduce the size of the Profile class by having
static "GetXyzForProfile" functions e.g. PluginPrefsFactory::GetPrefsForProfile
retrieves a PluginPrefs object for the specified profile.  But taking it one
step further so that it's a static method on the interface itself lets you
completely divorce from implementation details such as the question whether the
thing is implemented as, say, a ProfileKeyedService or as an object owned by
Profile that you get via an accessor - and that is a good thing since that means
things can migrate to e.g. ProfileKeyedServices over time, without the API
changing.

http://codereview.chromium.org/10828345/diff/1/chrome/browser/prefs/pref_serv...
File chrome/browser/prefs/pref_service.h (right):

http://codereview.chromium.org/10828345/diff/1/chrome/browser/prefs/pref_serv...
chrome/browser/prefs/pref_service.h:32: class NotificationObserver;
On 2012/08/16 15:12:40, erikwright wrote:
> I think this can be removed since it is part of the implemented API, thus not
> considered transitive.

Done.

[Jói, 2012-08-16 15:38:09]

As a side note, I'm happy to report that the trybots also caught the
issue that Mattias pointed out in pref_member.cc :-)

On Thu, Aug 16, 2012 at 3:35 PM,  <[email protected]> wrote:
> Will wait to upload a new patch until I hear back from Mattias and implement
> whatever solution we come up with for the FindPreference issue in
> pref_value.cc
>
>
>
>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
> File chrome/browser/api/prefs/pref_service_base.h (right):
>
>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
> chrome/browser/api/prefs/pref_service_base.h:35: // Retrieves a
> PrefServiceBase for the given profile.
> On 2012/08/16 15:12:40, erikwright wrote:
>>
>> I'm not a big fan of this. Is there a reason why Profile::GetPrefs
>
> can't return
>>
>> a PrefServiceBase?
>
>
>> Presumably in the long term it won't be necessary. Perhaps in the
>
> meantime we
>>
>> could add Profile::GetPrefServiceBase?
>
>
> First off I should note that we want to stop depending on Profile.
>
> I actually think this is a good pattern as it makes the implementation
> more
> independent of the interfaces.  More and more I've been thinking we
> should
> introduce a ProfileHandle, TabHandle, and perhaps other XyzHandle base
> classes
> for things like Profile, TabContents, etc. that we don't want Browser
> Components
> to depend on but which lots of services hang off of.  Then we can have
> ForXyz
> static methods that are fulfilled at link time to retrieve the current
> browser's
> implementation of these, and break the dependency on the concrete
> implementation
> and the details of its structure, except for the fact that you can get
> e.g. a
> PrefServiceBase from a Profile.
>
> In content, we have at least a couple of examples of static methods
> named
> ForXyz, and we have several named FromXyz.  The latter are used for
> methods that
> cast from one type to another, so I think ForXyz is the most appropriate
> convention.
>
> I'm happy to discuss, but I think the alternative is to end up with huge
> big
> interfaces (say ProfileAPI or ProfileBase) that mirror most of the stuff
> from
> these big objects like Profile and TabContents, and importantly, may
> have
> significant per-platform differences.
>
> This approach also takes a cue from the ProfileKeyedService approach
> that has
> been used with great success to reduce the size of the Profile class by
> having
> static "GetXyzForProfile" functions e.g.
> PluginPrefsFactory::GetPrefsForProfile
> retrieves a PluginPrefs object for the specified profile.  But taking it
> one
> step further so that it's a static method on the interface itself lets
> you
> completely divorce from implementation details such as the question
> whether the
> thing is implemented as, say, a ProfileKeyedService or as an object
> owned by
> Profile that you get via an accessor - and that is a good thing since
> that means
> things can migrate to e.g. ProfileKeyedServices over time, without the
> API
> changing.
>
>
>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/prefs/pref_serv...
> File chrome/browser/prefs/pref_service.h (right):
>
>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/prefs/pref_serv...
> chrome/browser/prefs/pref_service.h:32: class NotificationObserver;
> On 2012/08/16 15:12:40, erikwright wrote:
>>
>> I think this can be removed since it is part of the implemented API,
>
> thus not
>>
>> considered transitive.
>
>
> Done.
>
> http://codereview.chromium.org/10828345/

[erikwright (departed), 2012-08-16 15:55:47]

Having a 'ForProfile' that is meant to be satisfied by the implementation
at link-time is not a long-term solution because (1) it implies there will
be only a single implementation in any binary (or at least, all
implementations need to coordinate to provide a single implementation with
the decision-making logic) and (2) it prevents replacing the implementation
during unit-tests if those unit tests also link to the implementation
(which they shouldn't eventually, but likely will for the foreseeable
future).

A browser component that depends on a PrefServiceBase* should should be
handed one when it is configured. So no proper browser component should use
this method.

Can we then move it out of api/ so that components will be forced to have
an exception in order to use this, helping us to keep track of remaining
non-conformance?

On Thu, Aug 16, 2012 at 11:34 AM, <[email protected]> wrote:

>
> http://codereview.chromium.**org/10828345/diff/1/chrome/**
>
browser/api/prefs/pref_member.**cc<http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_member.cc>
> File chrome/browser/api/prefs/pref_**member.cc (right):
>
> http://codereview.chromium.**org/10828345/diff/1/chrome/**
>
browser/api/prefs/pref_member.**cc#newcode38<http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_member.cc#newcode38>
> chrome/browser/api/prefs/pref_**member.cc:38:
> DCHECK(prefs_->**GetUserPrefValue(pref_name_.c_**str()))
> On 2012/08/16 15:16:42, Mattias Nissler wrote:
>
>> Wait, what's this? This is incorrect.
>>
>
> See below.
>
>
> http://codereview.chromium.**org/10828345/diff/1/chrome/**
>
browser/api/prefs/pref_member.**cc#newcode75<http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_member.cc#newcode75>
> chrome/browser/api/prefs/pref_**member.cc:75:
> prefs_->GetUserPrefValue(pref_**name_.c_str())->DeepCopy(),
> On 2012/08/16 15:16:42, Mattias Nissler wrote:
>
>> also incorrect
>>
>
> This, and the thing above, was me trying to get rid of FindPreference
> from the base API.  I misread the GetUserPrefValue documentation, and I
> see now that this is not equivalent.
>
> I wonder if I should instead simply add GetPrefValue(name) which returns
> a base::Value* like these two guys, but basically just does
> FindPreference(name)->**GetValue().  I think that would make both places
> equivalent, although the DCHECK at the top would be checking a different
> thing it should be semantically the same?
>
>
http://codereview.chromium.**org/10828345/<http://codereview.chromium.org/108...
>

[Jói, 2012-08-16 16:40:48]

Having a way to access an X for a Y that the implementation can fill
at link time seems to me about as dynamic as it needs to be.

There is a significant cost to going whole-hog on dependency
injection.  We wouldn't be able to inject a single PrefServiceBase*
(since it is per-profile, not global) but we could inject a function
pointer with the same signature as (e.g.) PrefServiceBase::ForProfile,
or a factory-like object with essentially the same semantics.  There
is an explosion in the complexity of initializing and using components
that do this for everything, so we need to be sure the cost of this
complexity is worth it.

If for a given platform we only foresee a production implementation
and a test implementation (or multiple test implementations) then
there is no real need to go all the way to dependency injection.  A
cheaper alternative that is used for many of our tests already is to
have a factory for creating the objects, the implementation of which
can be switched out while unit tests are running (e.g. by changing a
function pointer that the factory defers to, or by implementing the
factory function in terms of an object that can be switched out).

> Can we then move it out of api/ so that components will be forced to have an
> exception in order to use this, helping us to keep track of remaining
> non-conformance?

If the consensus after discussing the above is that using static
factories/accessors in the APIs is not acceptable as a long-term
approach, then we can and we should.

I'm happy to discuss by phone or VC if it's more efficient.

Cheers,
Jói



On Thu, Aug 16, 2012 at 3:55 PM, Erik Wright <[email protected]> wrote:
> Having a 'ForProfile' that is meant to be satisfied by the implementation at
> link-time is not a long-term solution because (1) it implies there will be
> only a single implementation in any binary (or at least, all implementations
> need to coordinate to provide a single implementation with the
> decision-making logic) and (2) it prevents replacing the implementation
> during unit-tests if those unit tests also link to the implementation (which
> they shouldn't eventually, but likely will for the foreseeable future).
>
> A browser component that depends on a PrefServiceBase* should should be
> handed one when it is configured. So no proper browser component should use
> this method.
>
> Can we then move it out of api/ so that components will be forced to have an
> exception in order to use this, helping us to keep track of remaining
> non-conformance?
>
> On Thu, Aug 16, 2012 at 11:34 AM, <[email protected]> wrote:
>>
>>
>>
>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>> File chrome/browser/api/prefs/pref_member.cc (right):
>>
>>
>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>> chrome/browser/api/prefs/pref_member.cc:38:
>> DCHECK(prefs_->GetUserPrefValue(pref_name_.c_str()))
>> On 2012/08/16 15:16:42, Mattias Nissler wrote:
>>>
>>> Wait, what's this? This is incorrect.
>>
>>
>> See below.
>>
>>
>>
>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>> chrome/browser/api/prefs/pref_member.cc:75:
>> prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
>> On 2012/08/16 15:16:42, Mattias Nissler wrote:
>>>
>>> also incorrect
>>
>>
>> This, and the thing above, was me trying to get rid of FindPreference
>> from the base API.  I misread the GetUserPrefValue documentation, and I
>> see now that this is not equivalent.
>>
>> I wonder if I should instead simply add GetPrefValue(name) which returns
>> a base::Value* like these two guys, but basically just does
>> FindPreference(name)->GetValue().  I think that would make both places
>> equivalent, although the DCHECK at the top would be checking a different
>> thing it should be semantically the same?
>>
>> http://codereview.chromium.org/10828345/
>
>

[Jói, 2012-08-16 16:43:10]

I meant to highlight that there is a similar thing in
http://codereview.chromium.org/10830353/, which I am awaiting your
review on (and pkasting's).  It is InfoBarTabService::GetInstance, and
I was planning to change its name to InfoBarTabService::FromTab to
match the current change.

Cheers,
Jói

On Thu, Aug 16, 2012 at 4:40 PM, Jói Sigurðsson <[email protected]> wrote:
> Having a way to access an X for a Y that the implementation can fill
> at link time seems to me about as dynamic as it needs to be.
>
> There is a significant cost to going whole-hog on dependency
> injection.  We wouldn't be able to inject a single PrefServiceBase*
> (since it is per-profile, not global) but we could inject a function
> pointer with the same signature as (e.g.) PrefServiceBase::ForProfile,
> or a factory-like object with essentially the same semantics.  There
> is an explosion in the complexity of initializing and using components
> that do this for everything, so we need to be sure the cost of this
> complexity is worth it.
>
> If for a given platform we only foresee a production implementation
> and a test implementation (or multiple test implementations) then
> there is no real need to go all the way to dependency injection.  A
> cheaper alternative that is used for many of our tests already is to
> have a factory for creating the objects, the implementation of which
> can be switched out while unit tests are running (e.g. by changing a
> function pointer that the factory defers to, or by implementing the
> factory function in terms of an object that can be switched out).
>
>> Can we then move it out of api/ so that components will be forced to have an
>> exception in order to use this, helping us to keep track of remaining
>> non-conformance?
>
> If the consensus after discussing the above is that using static
> factories/accessors in the APIs is not acceptable as a long-term
> approach, then we can and we should.
>
> I'm happy to discuss by phone or VC if it's more efficient.
>
> Cheers,
> Jói
>
>
>
> On Thu, Aug 16, 2012 at 3:55 PM, Erik Wright <[email protected]> wrote:
>> Having a 'ForProfile' that is meant to be satisfied by the implementation at
>> link-time is not a long-term solution because (1) it implies there will be
>> only a single implementation in any binary (or at least, all implementations
>> need to coordinate to provide a single implementation with the
>> decision-making logic) and (2) it prevents replacing the implementation
>> during unit-tests if those unit tests also link to the implementation (which
>> they shouldn't eventually, but likely will for the foreseeable future).
>>
>> A browser component that depends on a PrefServiceBase* should should be
>> handed one when it is configured. So no proper browser component should use
>> this method.
>>
>> Can we then move it out of api/ so that components will be forced to have an
>> exception in order to use this, helping us to keep track of remaining
>> non-conformance?
>>
>> On Thu, Aug 16, 2012 at 11:34 AM, <[email protected]> wrote:
>>>
>>>
>>>
>>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>>> File chrome/browser/api/prefs/pref_member.cc (right):
>>>
>>>
>>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>>> chrome/browser/api/prefs/pref_member.cc:38:
>>> DCHECK(prefs_->GetUserPrefValue(pref_name_.c_str()))
>>> On 2012/08/16 15:16:42, Mattias Nissler wrote:
>>>>
>>>> Wait, what's this? This is incorrect.
>>>
>>>
>>> See below.
>>>
>>>
>>>
>>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>>> chrome/browser/api/prefs/pref_member.cc:75:
>>> prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
>>> On 2012/08/16 15:16:42, Mattias Nissler wrote:
>>>>
>>>> also incorrect
>>>
>>>
>>> This, and the thing above, was me trying to get rid of FindPreference
>>> from the base API.  I misread the GetUserPrefValue documentation, and I
>>> see now that this is not equivalent.
>>>
>>> I wonder if I should instead simply add GetPrefValue(name) which returns
>>> a base::Value* like these two guys, but basically just does
>>> FindPreference(name)->GetValue().  I think that would make both places
>>> equivalent, although the DCHECK at the top would be checking a different
>>> thing it should be semantically the same?
>>>
>>> http://codereview.chromium.org/10828345/
>>
>>

[Mattias Nissler (ping if slow), 2012-08-16 16:48:33]

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
File chrome/browser/api/prefs/pref_member.cc (right):

http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
chrome/browser/api/prefs/pref_member.cc:75:
prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
On 2012/08/16 15:34:18, Jói wrote:
> On 2012/08/16 15:16:42, Mattias Nissler wrote:
> > also incorrect
> 
> This, and the thing above, was me trying to get rid of FindPreference from the
> base API.  I misread the GetUserPrefValue documentation, and I see now that
this
> is not equivalent.
> 
> I wonder if I should instead simply add GetPrefValue(name) which returns a
> base::Value* like these two guys, but basically just does
> FindPreference(name)->GetValue().  I think that would make both places
> equivalent, although the DCHECK at the top would be checking a different thing
> it should be semantically the same?

You could indeed make a GetValue() function on PrefService (it's OK to expose
that), and then call that from Preference::GetValue(). Then again, I would
consider PrefService::Preference to be part of the generic interface actually,
so I'd feel better if that piece would move to PrefServiceBase as well.

[Jói, 2012-08-16 16:59:17]

> You could indeed make a GetValue() function on PrefService (it's OK to expose
> that), and then call that from Preference::GetValue(). Then again, I would
> consider PrefService::Preference to be part of the generic interface actually,
> so I'd feel better if that piece would move to PrefServiceBase as well.

To me, if we expose PrefService::Preference, we kind of double the API surface,
since it has a lot of the same stuff you can get via what I currently put into
PrefServiceBase; it kind of seems like it should be one or the other.  I think
it feels like an implementation detail primarily.

I looked for usages of FindPreference and a large portion of them seem to be
just checking for NULL, so would be served by exposing a method to check for
that.  The rest seem like they could be implemented in other terms if needed -
but then again there is no need to change the implementation for stuff that will
not become a component.

Finally, there is some added difficulty including Preference in
chrome/browser/api because it has a concrete dependency on PrefValueStore that
would then need to be broken, etc., but this shouldn't be a large factor; we
should choose what we think is the best API and implement that.

Let me know what you think about the points I make above.  I'm not the expert on
this code, you are.  My opinions may be colored by the fact that the shortest
path to completing my current patch seems to be to add the GetValue accessor to
PrefServiceBase and call it a day :)

Cheers,
Jói


On 2012/08/16 16:48:33, Mattias Nissler wrote:
>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
> File chrome/browser/api/prefs/pref_member.cc (right):
> 
>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
> chrome/browser/api/prefs/pref_member.cc:75:
> prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
> On 2012/08/16 15:34:18, Jói wrote:
> > On 2012/08/16 15:16:42, Mattias Nissler wrote:
> > > also incorrect
> > 
> > This, and the thing above, was me trying to get rid of FindPreference from
the
> > base API.  I misread the GetUserPrefValue documentation, and I see now that
> this
> > is not equivalent.
> > 
> > I wonder if I should instead simply add GetPrefValue(name) which returns a
> > base::Value* like these two guys, but basically just does
> > FindPreference(name)->GetValue().  I think that would make both places
> > equivalent, although the DCHECK at the top would be checking a different
thing
> > it should be semantically the same?
> 
> You could indeed make a GetValue() function on PrefService (it's OK to expose
> that), and then call that from Preference::GetValue(). Then again, I would
> consider PrefService::Preference to be part of the generic interface actually,
> so I'd feel better if that piece would move to PrefServiceBase as well.

[Mattias Nissler (ping if slow), 2012-08-16 18:08:10]

On Thu, Aug 16, 2012 at 6:59 PM, <[email protected]> wrote:

>  You could indeed make a GetValue() function on PrefService (it's OK to
>> expose
>> that), and then call that from Preference::GetValue(). Then again, I would
>> consider PrefService::Preference to be part of the generic interface
>> actually,
>> so I'd feel better if that piece would move to PrefServiceBase as well.
>>
>
> To me, if we expose PrefService::Preference, we kind of double the API
> surface,
> since it has a lot of the same stuff you can get via what I currently put
> into
> PrefServiceBase; it kind of seems like it should be one or the other.  I
> think
> it feels like an implementation detail primarily.
>

It's true that there is some duplication at the moment. I think the
original deal was that you'd use PrefService::Preference to find
information about the preference other than the value. People have added
convenience helpers to PrefService over time.


> I looked for usages of FindPreference and a large portion of them seem to
> be
> just checking for NULL, so would be served by exposing a method to check
> for
> that.  The rest seem like they could be implemented in other terms if
> needed -
> but then again there is no need to change the implementation for stuff
> that will
> not become a component.
>

I don't think it's a good idea to have a blessed API, and then have a
second thing you can use if you're in the right subdirectory. I thought one
of the goals of the browser API project is to actually create a sane API?
IMHO it would be better to make a good decision and then migrate everybody
to that.


>
> Finally, there is some added difficulty including Preference in
> chrome/browser/api because it has a concrete dependency on PrefValueStore
> that
> would then need to be broken, etc., but this shouldn't be a large factor;
> we
> should choose what we think is the best API and implement that.
>

That's an implementation detail that shouldn't guide our decision on how we
would like the API to look like too much.

Let me know what you think about the points I make above.  I'm not the
> expert on
> this code, you are.  My opinions may be colored by the fact that the
> shortest
> path to completing my current patch seems to be to add the GetValue
> accessor to
> PrefServiceBase and call it a day :)
>

I understand that :) If you want to do that for now, I'm not going to
object. I'll need to think more about what the preferred API would be from
my point of view. Also adding the other chrome/browser/prefs maintainers in
case they have an idea.


>
> Cheers,
> Jói
>
>
>
> On 2012/08/16 16:48:33, Mattias Nissler wrote:
>
> http://codereview.chromium.**org/10828345/diff/1/chrome/**
>
browser/api/prefs/pref_member.**cc<http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_member.cc>
>
>> File chrome/browser/api/prefs/pref_**member.cc (right):
>>
>
>
> http://codereview.chromium.**org/10828345/diff/1/chrome/**
>
browser/api/prefs/pref_member.**cc#newcode75<http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_member.cc#newcode75>
>
>> chrome/browser/api/prefs/pref_**member.cc:75:
>> prefs_->GetUserPrefValue(pref_**name_.c_str())->DeepCopy(),
>> On 2012/08/16 15:34:18, Jói wrote:
>> > On 2012/08/16 15:16:42, Mattias Nissler wrote:
>> > > also incorrect
>> >
>> > This, and the thing above, was me trying to get rid of FindPreference
>> from
>>
> the
>
>> > base API.  I misread the GetUserPrefValue documentation, and I see now
>> that
>> this
>> > is not equivalent.
>> >
>> > I wonder if I should instead simply add GetPrefValue(name) which
>> returns a
>> > base::Value* like these two guys, but basically just does
>> > FindPreference(name)->**GetValue().  I think that would make both
>> places
>> > equivalent, although the DCHECK at the top would be checking a different
>>
> thing
>
>> > it should be semantically the same?
>>
>
>  You could indeed make a GetValue() function on PrefService (it's OK to
>> expose
>> that), and then call that from Preference::GetValue(). Then again, I would
>> consider PrefService::Preference to be part of the generic interface
>> actually,
>> so I'd feel better if that piece would move to PrefServiceBase as well.
>>
>
>
>
>
http://codereview.chromium.**org/10828345/<http://codereview.chromium.org/108...
>

[Bernhard Bauer, 2012-08-16 18:47:59]

I also that feel PrefService::Preference is a part of the API, and the
methods in PrefService are convenience methods that use that API. That
being said, we should probably look at the callers. If they only use
Preference to check whether a preference is registered, maybe it would make
sense to get rid of Preference completely and just store a map from pref
name to type.

On Thu, Aug 16, 2012 at 8:07 PM, Mattias Nissler <[email protected]>wrote:

>
>
> On Thu, Aug 16, 2012 at 6:59 PM, <[email protected]> wrote:
>
>>  You could indeed make a GetValue() function on PrefService (it's OK to
>>> expose
>>> that), and then call that from Preference::GetValue(). Then again, I
>>> would
>>> consider PrefService::Preference to be part of the generic interface
>>> actually,
>>> so I'd feel better if that piece would move to PrefServiceBase as well.
>>>
>>
>> To me, if we expose PrefService::Preference, we kind of double the API
>> surface,
>> since it has a lot of the same stuff you can get via what I currently put
>> into
>> PrefServiceBase; it kind of seems like it should be one or the other.  I
>> think
>> it feels like an implementation detail primarily.
>>
>
> It's true that there is some duplication at the moment. I think the
> original deal was that you'd use PrefService::Preference to find
> information about the preference other than the value. People have added
> convenience helpers to PrefService over time.
>
>
>> I looked for usages of FindPreference and a large portion of them seem to
>> be
>> just checking for NULL, so would be served by exposing a method to check
>> for
>> that.  The rest seem like they could be implemented in other terms if
>> needed -
>> but then again there is no need to change the implementation for stuff
>> that will
>> not become a component.
>>
>
> I don't think it's a good idea to have a blessed API, and then have a
> second thing you can use if you're in the right subdirectory. I thought one
> of the goals of the browser API project is to actually create a sane API?
> IMHO it would be better to make a good decision and then migrate everybody
> to that.
>
>
>>
>> Finally, there is some added difficulty including Preference in
>> chrome/browser/api because it has a concrete dependency on PrefValueStore
>> that
>> would then need to be broken, etc., but this shouldn't be a large factor;
>> we
>> should choose what we think is the best API and implement that.
>
>
I would have assumed if we move Preference to api/ that we'd create an
interface class like for PrefService. The implementation of that interface
can then depend on PrefValueStore.


> That's an implementation detail that shouldn't guide our decision on how
> we would like the API to look like too much.
>
> Let me know what you think about the points I make above.  I'm not the
>> expert on
>> this code, you are.  My opinions may be colored by the fact that the
>> shortest
>> path to completing my current patch seems to be to add the GetValue
>> accessor to
>> PrefServiceBase and call it a day :)
>>
>
> I understand that :) If you want to do that for now, I'm not going to
> object. I'll need to think more about what the preferred API would be from
> my point of view. Also adding the other chrome/browser/prefs maintainers in
> case they have an idea.
>
>
>>
>> Cheers,
>> Jói
>>
>>
>>
>> On 2012/08/16 16:48:33, Mattias Nissler wrote:
>>
>> http://codereview.chromium.**org/10828345/diff/1/chrome/**
>>
browser/api/prefs/pref_member.**cc<http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_member.cc>
>>
>>> File chrome/browser/api/prefs/pref_**member.cc (right):
>>>
>>
>>
>> http://codereview.chromium.**org/10828345/diff/1/chrome/**
>>
browser/api/prefs/pref_member.**cc#newcode75<http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_member.cc#newcode75>
>>
>>> chrome/browser/api/prefs/pref_**member.cc:75:
>>> prefs_->GetUserPrefValue(pref_**name_.c_str())->DeepCopy(),
>>> On 2012/08/16 15:34:18, Jói wrote:
>>> > On 2012/08/16 15:16:42, Mattias Nissler wrote:
>>> > > also incorrect
>>> >
>>> > This, and the thing above, was me trying to get rid of FindPreference
>>> from
>>>
>> the
>>
>>> > base API.  I misread the GetUserPrefValue documentation, and I see now
>>> that
>>> this
>>> > is not equivalent.
>>> >
>>> > I wonder if I should instead simply add GetPrefValue(name) which
>>> returns a
>>> > base::Value* like these two guys, but basically just does
>>> > FindPreference(name)->**GetValue().  I think that would make both
>>> places
>>> > equivalent, although the DCHECK at the top would be checking a
>>> different
>>>
>> thing
>>
>>> > it should be semantically the same?
>>>
>>
>>  You could indeed make a GetValue() function on PrefService (it's OK to
>>> expose
>>> that), and then call that from Preference::GetValue(). Then again, I
>>> would
>>> consider PrefService::Preference to be part of the generic interface
>>> actually,
>>> so I'd feel better if that piece would move to PrefServiceBase as well.
>>>
>>
>>
>>
>>
http://codereview.chromium.**org/10828345/<http://codereview.chromium.org/108...
>>
>
>

[Jói, 2012-08-16 22:23:58]

Thanks for the feedback, Bernhard and Mattias.

From the quick look I took earlier today, it seemed most of the
callers are either using FindPreference to check for its existence
(i.e. they are doing a NULL check) or to retrieve its value, or to
check whether it has its default value, all of which is or could be
made available through the pref name-based methods.

However, it seems from your comments that exposing Preference would be
the more natural API.  I think this is perfectly doable, and I think
it's OK to leave in the convenience functions.  However, one caveat I
can think of is whether you want to expose in the API that there are
separate stores for default values vs. user-specified values?  This
ties the hands of the implementation a little bit since then any
implementation would have to separate them the same way.  Might be OK,
but it's a concern for the API and I had left this out in the version
I uploaded.  If we expose all of the public interface of Preference,
then this idea would also be exposed.

>> I don't think it's a good idea to have a blessed API, and then have a
>> second thing you can use if you're in the right subdirectory. I thought one
>> of the goals of the browser API project is to actually create a sane API?
>> IMHO it would be better to make a good decision and then migrate everybody
>> to that.

This might be true for most users of prefs.  However, in general:  We
want to create a sane API, and we want to switch all code that
eventually should be a Browser Component to using the API.  On the
other hand, there is code that we don't expect to be a consumer of
APIs, but more like a provider of them, and since the API will never
expose all of the subtleties of the underlying implementation, there
may be cases where it is better for the implementation to keep talking
in concrete terms so that the APIs can be left simple rather than
introducing more and more functionality to them that is only used as
an implementation detail.  Because of this doubt, at least for now, I
don't think it should be an explicit goal to switch _everybody_ over
to using each new API we define, but for sure anything that is going
to become a Browser Component will eventually be switched over, and is
OK to switch over as early as anybody wants to do it (as a team, we're
going more component-by-component so e.g. I'm working on Autofill and
defining the prefs API and will switch Autofill over, but probably
leave a bunch of other destined-to-be-Browser-Components code over
later, as we get to those components).

Cheers,
Jói


On Thu, Aug 16, 2012 at 6:47 PM, Bernhard Bauer <[email protected]> wrote:
> I also that feel PrefService::Preference is a part of the API, and the
> methods in PrefService are convenience methods that use that API. That being
> said, we should probably look at the callers. If they only use Preference to
> check whether a preference is registered, maybe it would make sense to get
> rid of Preference completely and just store a map from pref name to type.
>
> On Thu, Aug 16, 2012 at 8:07 PM, Mattias Nissler <[email protected]>
> wrote:
>>
>>
>>
>> On Thu, Aug 16, 2012 at 6:59 PM, <[email protected]> wrote:
>>>>
>>>> You could indeed make a GetValue() function on PrefService (it's OK to
>>>> expose
>>>> that), and then call that from Preference::GetValue(). Then again, I
>>>> would
>>>> consider PrefService::Preference to be part of the generic interface
>>>> actually,
>>>> so I'd feel better if that piece would move to PrefServiceBase as well.
>>>
>>>
>>> To me, if we expose PrefService::Preference, we kind of double the API
>>> surface,
>>> since it has a lot of the same stuff you can get via what I currently put
>>> into
>>> PrefServiceBase; it kind of seems like it should be one or the other.  I
>>> think
>>> it feels like an implementation detail primarily.
>>
>>
>> It's true that there is some duplication at the moment. I think the
>> original deal was that you'd use PrefService::Preference to find information
>> about the preference other than the value. People have added convenience
>> helpers to PrefService over time.
>>
>>>
>>> I looked for usages of FindPreference and a large portion of them seem to
>>> be
>>> just checking for NULL, so would be served by exposing a method to check
>>> for
>>> that.  The rest seem like they could be implemented in other terms if
>>> needed -
>>> but then again there is no need to change the implementation for stuff
>>> that will
>>> not become a component.
>>
>>
>> I don't think it's a good idea to have a blessed API, and then have a
>> second thing you can use if you're in the right subdirectory. I thought one
>> of the goals of the browser API project is to actually create a sane API?
>> IMHO it would be better to make a good decision and then migrate everybody
>> to that.
>>
>>>
>>>
>>> Finally, there is some added difficulty including Preference in
>>> chrome/browser/api because it has a concrete dependency on PrefValueStore
>>> that
>>> would then need to be broken, etc., but this shouldn't be a large factor;
>>> we
>>> should choose what we think is the best API and implement that.
>
>
> I would have assumed if we move Preference to api/ that we'd create an
> interface class like for PrefService. The implementation of that interface
> can then depend on PrefValueStore.
>
>>
>> That's an implementation detail that shouldn't guide our decision on how
>> we would like the API to look like too much.
>>
>>> Let me know what you think about the points I make above.  I'm not the
>>> expert on
>>> this code, you are.  My opinions may be colored by the fact that the
>>> shortest
>>> path to completing my current patch seems to be to add the GetValue
>>> accessor to
>>> PrefServiceBase and call it a day :)
>>
>>
>> I understand that :) If you want to do that for now, I'm not going to
>> object. I'll need to think more about what the preferred API would be from
>> my point of view. Also adding the other chrome/browser/prefs maintainers in
>> case they have an idea.
>>
>>>
>>>
>>> Cheers,
>>> Jói
>>>
>>>
>>>
>>> On 2012/08/16 16:48:33, Mattias Nissler wrote:
>>>
>>>
>>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>>>>
>>>> File chrome/browser/api/prefs/pref_member.cc (right):
>>>
>>>
>>>
>>>
>>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>>>>
>>>> chrome/browser/api/prefs/pref_member.cc:75:
>>>> prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
>>>> On 2012/08/16 15:34:18, Jói wrote:
>>>> > On 2012/08/16 15:16:42, Mattias Nissler wrote:
>>>> > > also incorrect
>>>> >
>>>> > This, and the thing above, was me trying to get rid of FindPreference
>>>> > from
>>>
>>> the
>>>>
>>>> > base API.  I misread the GetUserPrefValue documentation, and I see now
>>>> > that
>>>> this
>>>> > is not equivalent.
>>>> >
>>>> > I wonder if I should instead simply add GetPrefValue(name) which
>>>> > returns a
>>>> > base::Value* like these two guys, but basically just does
>>>> > FindPreference(name)->GetValue().  I think that would make both places
>>>> > equivalent, although the DCHECK at the top would be checking a
>>>> > different
>>>
>>> thing
>>>>
>>>> > it should be semantically the same?
>>>
>>>
>>>> You could indeed make a GetValue() function on PrefService (it's OK to
>>>> expose
>>>> that), and then call that from Preference::GetValue(). Then again, I
>>>> would
>>>> consider PrefService::Preference to be part of the generic interface
>>>> actually,
>>>> so I'd feel better if that piece would move to PrefServiceBase as well.
>>>
>>>
>>>
>>>
>>> http://codereview.chromium.org/10828345/
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "browser-components-watch" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit
> https://groups.google.com/a/chromium.org/groups/opt_out.
>
>

[Mattias Nissler (ping if slow), 2012-08-17 08:14:24]

On Fri, Aug 17, 2012 at 12:23 AM, Jói Sigurðsson <[email protected]> wrote:

> Thanks for the feedback, Bernhard and Mattias.
>
> From the quick look I took earlier today, it seemed most of the
> callers are either using FindPreference to check for its existence
> (i.e. they are doing a NULL check) or to retrieve its value, or to
> check whether it has its default value, all of which is or could be
> made available through the pref name-based methods.
>
> However, it seems from your comments that exposing Preference would be
> the more natural API.  I think this is perfectly doable, and I think
> it's OK to leave in the convenience functions.  However, one caveat I
> can think of is whether you want to expose in the API that there are
> separate stores for default values vs. user-specified values?


I'm not sure what you mean by "expose". If you refer to the existence of
GetDefaultValue() and GetUserPrefValue(), then yes, we want that. But
that's more on a semantic level: We expose that there are different logical
origins for values, but how we store them is still opaque.


> This
> ties the hands of the implementation a little bit since then any
> implementation would have to separate them the same way.  Might be OK,
> but it's a concern for the API and I had left this out in the version
> I uploaded.  If we expose all of the public interface of Preference,
> then this idea would also be exposed.
>
> >> I don't think it's a good idea to have a blessed API, and then have a
> >> second thing you can use if you're in the right subdirectory. I thought
> one
> >> of the goals of the browser API project is to actually create a sane
> API?
> >> IMHO it would be better to make a good decision and then migrate
> everybody
> >> to that.
>
> This might be true for most users of prefs.  However, in general:  We
> want to create a sane API, and we want to switch all code that
> eventually should be a Browser Component to using the API.  On the
> other hand, there is code that we don't expect to be a consumer of
> APIs, but more like a provider of them, and since the API will never
> expose all of the subtleties of the underlying implementation, there
> may be cases where it is better for the implementation to keep talking
> in concrete terms so that the APIs can be left simple rather than
> introducing more and more functionality to them that is only used as
> an implementation detail.  Because of this doubt, at least for now, I
> don't think it should be an explicit goal to switch _everybody_ over
> to using each new API we define, but for sure anything that is going
> to become a Browser Component will eventually be switched over, and is
> OK to switch over as early as anybody wants to do it (as a team, we're
> going more component-by-component so e.g. I'm working on Autofill and
> defining the prefs API and will switch Autofill over, but probably
> leave a bunch of other destined-to-be-Browser-Components code over
> later, as we get to those components).
>

Simple answer here: Everything in chrome/browser/prefs is in the bucket of
"provider" code. Everybody else is consumer (except maybe for PrefService
construction, but that's an edge case), including code below chrome/ that's
not going to be a browser component. No matter whether component or not, it
should use one public PrefService API (and I expect that'll be the one
we're just deciding on).


> Cheers,
> Jói
>
>
> On Thu, Aug 16, 2012 at 6:47 PM, Bernhard Bauer <[email protected]>
> wrote:
> > I also that feel PrefService::Preference is a part of the API, and the
> > methods in PrefService are convenience methods that use that API. That
> being
> > said, we should probably look at the callers. If they only use
> Preference to
> > check whether a preference is registered, maybe it would make sense to
> get
> > rid of Preference completely and just store a map from pref name to type.
> >
> > On Thu, Aug 16, 2012 at 8:07 PM, Mattias Nissler <[email protected]>
> > wrote:
> >>
> >>
> >>
> >> On Thu, Aug 16, 2012 at 6:59 PM, <[email protected]> wrote:
> >>>>
> >>>> You could indeed make a GetValue() function on PrefService (it's OK to
> >>>> expose
> >>>> that), and then call that from Preference::GetValue(). Then again, I
> >>>> would
> >>>> consider PrefService::Preference to be part of the generic interface
> >>>> actually,
> >>>> so I'd feel better if that piece would move to PrefServiceBase as
> well.
> >>>
> >>>
> >>> To me, if we expose PrefService::Preference, we kind of double the API
> >>> surface,
> >>> since it has a lot of the same stuff you can get via what I currently
> put
> >>> into
> >>> PrefServiceBase; it kind of seems like it should be one or the other.
>  I
> >>> think
> >>> it feels like an implementation detail primarily.
> >>
> >>
> >> It's true that there is some duplication at the moment. I think the
> >> original deal was that you'd use PrefService::Preference to find
> information
> >> about the preference other than the value. People have added convenience
> >> helpers to PrefService over time.
> >>
> >>>
> >>> I looked for usages of FindPreference and a large portion of them seem
> to
> >>> be
> >>> just checking for NULL, so would be served by exposing a method to
> check
> >>> for
> >>> that.  The rest seem like they could be implemented in other terms if
> >>> needed -
> >>> but then again there is no need to change the implementation for stuff
> >>> that will
> >>> not become a component.
> >>
> >>
> >> I don't think it's a good idea to have a blessed API, and then have a
> >> second thing you can use if you're in the right subdirectory. I thought
> one
> >> of the goals of the browser API project is to actually create a sane
> API?
> >> IMHO it would be better to make a good decision and then migrate
> everybody
> >> to that.
> >>
> >>>
> >>>
> >>> Finally, there is some added difficulty including Preference in
> >>> chrome/browser/api because it has a concrete dependency on
> PrefValueStore
> >>> that
> >>> would then need to be broken, etc., but this shouldn't be a large
> factor;
> >>> we
> >>> should choose what we think is the best API and implement that.
> >
> >
> > I would have assumed if we move Preference to api/ that we'd create an
> > interface class like for PrefService. The implementation of that
> interface
> > can then depend on PrefValueStore.
> >
> >>
> >> That's an implementation detail that shouldn't guide our decision on how
> >> we would like the API to look like too much.
> >>
> >>> Let me know what you think about the points I make above.  I'm not the
> >>> expert on
> >>> this code, you are.  My opinions may be colored by the fact that the
> >>> shortest
> >>> path to completing my current patch seems to be to add the GetValue
> >>> accessor to
> >>> PrefServiceBase and call it a day :)
> >>
> >>
> >> I understand that :) If you want to do that for now, I'm not going to
> >> object. I'll need to think more about what the preferred API would be
> from
> >> my point of view. Also adding the other chrome/browser/prefs
> maintainers in
> >> case they have an idea.
> >>
> >>>
> >>>
> >>> Cheers,
> >>> Jói
> >>>
> >>>
> >>>
> >>> On 2012/08/16 16:48:33, Mattias Nissler wrote:
> >>>
> >>>
> >>>
>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
> >>>>
> >>>> File chrome/browser/api/prefs/pref_member.cc (right):
> >>>
> >>>
> >>>
> >>>
> >>>
>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
> >>>>
> >>>> chrome/browser/api/prefs/pref_member.cc:75:
> >>>> prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
> >>>> On 2012/08/16 15:34:18, Jói wrote:
> >>>> > On 2012/08/16 15:16:42, Mattias Nissler wrote:
> >>>> > > also incorrect
> >>>> >
> >>>> > This, and the thing above, was me trying to get rid of
> FindPreference
> >>>> > from
> >>>
> >>> the
> >>>>
> >>>> > base API.  I misread the GetUserPrefValue documentation, and I see
> now
> >>>> > that
> >>>> this
> >>>> > is not equivalent.
> >>>> >
> >>>> > I wonder if I should instead simply add GetPrefValue(name) which
> >>>> > returns a
> >>>> > base::Value* like these two guys, but basically just does
> >>>> > FindPreference(name)->GetValue().  I think that would make both
> places
> >>>> > equivalent, although the DCHECK at the top would be checking a
> >>>> > different
> >>>
> >>> thing
> >>>>
> >>>> > it should be semantically the same?
> >>>
> >>>
> >>>> You could indeed make a GetValue() function on PrefService (it's OK to
> >>>> expose
> >>>> that), and then call that from Preference::GetValue(). Then again, I
> >>>> would
> >>>> consider PrefService::Preference to be part of the generic interface
> >>>> actually,
> >>>> so I'd feel better if that piece would move to PrefServiceBase as
> well.
> >>>
> >>>
> >>>
> >>>
> >>> http://codereview.chromium.org/10828345/
> >>
> >>
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "browser-components-watch" group.
> > To post to this group, send email to
> [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit
> > https://groups.google.com/a/chromium.org/groups/opt_out.
> >
> >
>

[Jói, 2012-08-17 13:33:08]

Cool, thanks Mattias.  I can take a stab at a new version of the API
today, so that we can discuss it in concrete terms.

Sounds good to have the prefs API be the one and only way stuff
outside of chrome/browser/prefs should use prefs.  I think it's very
positive to do this.

Just so that I communicate clearly though:  I'm not signing myself or
the Browser Components team up to switch every piece of code in Chrome
over to the new API immediately.  We will switch over code within the
Browser Components we are extracting, as we work on them.  This should
by the time we're done be a very large percentage of the code base but
there may still be some code remaining that we haven't touched.

To help avoid new uses that bypass the API, the new "temporarily
allowed DEPS rules" feature can be used (see the docstring in
tools/checkdeps/checkdeps.py) to disallow code under chrome/browser
from using chrome/browser/prefs (but temporarily allow the existing
usages).  I'm happy to help get this set up if you like.

Cheers,
Jói


On Fri, Aug 17, 2012 at 8:14 AM, Mattias Nissler <[email protected]> wrote:
>
>
> On Fri, Aug 17, 2012 at 12:23 AM, Jói Sigurðsson <[email protected]> wrote:
>>
>> Thanks for the feedback, Bernhard and Mattias.
>>
>> From the quick look I took earlier today, it seemed most of the
>> callers are either using FindPreference to check for its existence
>> (i.e. they are doing a NULL check) or to retrieve its value, or to
>> check whether it has its default value, all of which is or could be
>> made available through the pref name-based methods.
>>
>> However, it seems from your comments that exposing Preference would be
>> the more natural API.  I think this is perfectly doable, and I think
>> it's OK to leave in the convenience functions.  However, one caveat I
>> can think of is whether you want to expose in the API that there are
>> separate stores for default values vs. user-specified values?
>
>
> I'm not sure what you mean by "expose". If you refer to the existence of
> GetDefaultValue() and GetUserPrefValue(), then yes, we want that. But that's
> more on a semantic level: We expose that there are different logical origins
> for values, but how we store them is still opaque.
>
>>
>> This
>> ties the hands of the implementation a little bit since then any
>> implementation would have to separate them the same way.  Might be OK,
>> but it's a concern for the API and I had left this out in the version
>> I uploaded.  If we expose all of the public interface of Preference,
>> then this idea would also be exposed.
>>
>> >> I don't think it's a good idea to have a blessed API, and then have a
>> >> second thing you can use if you're in the right subdirectory. I thought
>> >> one
>> >> of the goals of the browser API project is to actually create a sane
>> >> API?
>> >> IMHO it would be better to make a good decision and then migrate
>> >> everybody
>> >> to that.
>>
>> This might be true for most users of prefs.  However, in general:  We
>> want to create a sane API, and we want to switch all code that
>> eventually should be a Browser Component to using the API.  On the
>> other hand, there is code that we don't expect to be a consumer of
>> APIs, but more like a provider of them, and since the API will never
>> expose all of the subtleties of the underlying implementation, there
>> may be cases where it is better for the implementation to keep talking
>> in concrete terms so that the APIs can be left simple rather than
>> introducing more and more functionality to them that is only used as
>> an implementation detail.  Because of this doubt, at least for now, I
>> don't think it should be an explicit goal to switch _everybody_ over
>> to using each new API we define, but for sure anything that is going
>> to become a Browser Component will eventually be switched over, and is
>> OK to switch over as early as anybody wants to do it (as a team, we're
>> going more component-by-component so e.g. I'm working on Autofill and
>> defining the prefs API and will switch Autofill over, but probably
>> leave a bunch of other destined-to-be-Browser-Components code over
>> later, as we get to those components).
>
>
> Simple answer here: Everything in chrome/browser/prefs is in the bucket of
> "provider" code. Everybody else is consumer (except maybe for PrefService
> construction, but that's an edge case), including code below chrome/ that's
> not going to be a browser component. No matter whether component or not, it
> should use one public PrefService API (and I expect that'll be the one we're
> just deciding on).
>
>>
>> Cheers,
>> Jói
>>
>>
>> On Thu, Aug 16, 2012 at 6:47 PM, Bernhard Bauer <[email protected]>
>> wrote:
>> > I also that feel PrefService::Preference is a part of the API, and the
>> > methods in PrefService are convenience methods that use that API. That
>> > being
>> > said, we should probably look at the callers. If they only use
>> > Preference to
>> > check whether a preference is registered, maybe it would make sense to
>> > get
>> > rid of Preference completely and just store a map from pref name to
>> > type.
>> >
>> > On Thu, Aug 16, 2012 at 8:07 PM, Mattias Nissler <[email protected]>
>> > wrote:
>> >>
>> >>
>> >>
>> >> On Thu, Aug 16, 2012 at 6:59 PM, <[email protected]> wrote:
>> >>>>
>> >>>> You could indeed make a GetValue() function on PrefService (it's OK
>> >>>> to
>> >>>> expose
>> >>>> that), and then call that from Preference::GetValue(). Then again, I
>> >>>> would
>> >>>> consider PrefService::Preference to be part of the generic interface
>> >>>> actually,
>> >>>> so I'd feel better if that piece would move to PrefServiceBase as
>> >>>> well.
>> >>>
>> >>>
>> >>> To me, if we expose PrefService::Preference, we kind of double the API
>> >>> surface,
>> >>> since it has a lot of the same stuff you can get via what I currently
>> >>> put
>> >>> into
>> >>> PrefServiceBase; it kind of seems like it should be one or the other.
>> >>> I
>> >>> think
>> >>> it feels like an implementation detail primarily.
>> >>
>> >>
>> >> It's true that there is some duplication at the moment. I think the
>> >> original deal was that you'd use PrefService::Preference to find
>> >> information
>> >> about the preference other than the value. People have added
>> >> convenience
>> >> helpers to PrefService over time.
>> >>
>> >>>
>> >>> I looked for usages of FindPreference and a large portion of them seem
>> >>> to
>> >>> be
>> >>> just checking for NULL, so would be served by exposing a method to
>> >>> check
>> >>> for
>> >>> that.  The rest seem like they could be implemented in other terms if
>> >>> needed -
>> >>> but then again there is no need to change the implementation for stuff
>> >>> that will
>> >>> not become a component.
>> >>
>> >>
>> >> I don't think it's a good idea to have a blessed API, and then have a
>> >> second thing you can use if you're in the right subdirectory. I thought
>> >> one
>> >> of the goals of the browser API project is to actually create a sane
>> >> API?
>> >> IMHO it would be better to make a good decision and then migrate
>> >> everybody
>> >> to that.
>> >>
>> >>>
>> >>>
>> >>> Finally, there is some added difficulty including Preference in
>> >>> chrome/browser/api because it has a concrete dependency on
>> >>> PrefValueStore
>> >>> that
>> >>> would then need to be broken, etc., but this shouldn't be a large
>> >>> factor;
>> >>> we
>> >>> should choose what we think is the best API and implement that.
>> >
>> >
>> > I would have assumed if we move Preference to api/ that we'd create an
>> > interface class like for PrefService. The implementation of that
>> > interface
>> > can then depend on PrefValueStore.
>> >
>> >>
>> >> That's an implementation detail that shouldn't guide our decision on
>> >> how
>> >> we would like the API to look like too much.
>> >>
>> >>> Let me know what you think about the points I make above.  I'm not the
>> >>> expert on
>> >>> this code, you are.  My opinions may be colored by the fact that the
>> >>> shortest
>> >>> path to completing my current patch seems to be to add the GetValue
>> >>> accessor to
>> >>> PrefServiceBase and call it a day :)
>> >>
>> >>
>> >> I understand that :) If you want to do that for now, I'm not going to
>> >> object. I'll need to think more about what the preferred API would be
>> >> from
>> >> my point of view. Also adding the other chrome/browser/prefs
>> >> maintainers in
>> >> case they have an idea.
>> >>
>> >>>
>> >>>
>> >>> Cheers,
>> >>> Jói
>> >>>
>> >>>
>> >>>
>> >>> On 2012/08/16 16:48:33, Mattias Nissler wrote:
>> >>>
>> >>>
>> >>>
>> >>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>> >>>>
>> >>>> File chrome/browser/api/prefs/pref_member.cc (right):
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>> >>>>
>> >>>> chrome/browser/api/prefs/pref_member.cc:75:
>> >>>> prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
>> >>>> On 2012/08/16 15:34:18, Jói wrote:
>> >>>> > On 2012/08/16 15:16:42, Mattias Nissler wrote:
>> >>>> > > also incorrect
>> >>>> >
>> >>>> > This, and the thing above, was me trying to get rid of
>> >>>> > FindPreference
>> >>>> > from
>> >>>
>> >>> the
>> >>>>
>> >>>> > base API.  I misread the GetUserPrefValue documentation, and I see
>> >>>> > now
>> >>>> > that
>> >>>> this
>> >>>> > is not equivalent.
>> >>>> >
>> >>>> > I wonder if I should instead simply add GetPrefValue(name) which
>> >>>> > returns a
>> >>>> > base::Value* like these two guys, but basically just does
>> >>>> > FindPreference(name)->GetValue().  I think that would make both
>> >>>> > places
>> >>>> > equivalent, although the DCHECK at the top would be checking a
>> >>>> > different
>> >>>
>> >>> thing
>> >>>>
>> >>>> > it should be semantically the same?
>> >>>
>> >>>
>> >>>> You could indeed make a GetValue() function on PrefService (it's OK
>> >>>> to
>> >>>> expose
>> >>>> that), and then call that from Preference::GetValue(). Then again, I
>> >>>> would
>> >>>> consider PrefService::Preference to be part of the generic interface
>> >>>> actually,
>> >>>> so I'd feel better if that piece would move to PrefServiceBase as
>> >>>> well.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> http://codereview.chromium.org/10828345/
>> >>
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "browser-components-watch" group.
>> > To post to this group, send email to
>> > [email protected].
>> > To unsubscribe from this group, send email to
>> > [email protected].
>> > For more options, visit
>> > https://groups.google.com/a/chromium.org/groups/opt_out.
>> >
>> >
>
>

[Jói, 2012-08-17 15:24:06]

Erik and I had a discussion on using dependency injection vs. using
the X::ForY() approach that you see in the current change
(PrefServiceBase::ForProfile()).

To summarize:  We agreed there are benefits that can be realized using
dependency injection, e.g. a forced correct ordering at startup time,
which helps also order things correctly at shutdown, as well as
benefits related to unit testing and separation of concerns.  On the
flip side, we agreed that there are benefits to starting with the
X::ForY() approach now, since it lets us move faster and lets us
decouple the order in which we break dependencies from the order of
those dependencies (whereas when using dependency injection, it sort
of forces you to start bottom-up).  So our plan is to allow the
X::ForY() approach for now at least, and then revisit the idea of
using dependency injection more widely/systematically as we have
larger coverage in our APIs.

Cheers,
Jói


On Fri, Aug 17, 2012 at 1:32 PM, Jói Sigurðsson <[email protected]> wrote:
> Cool, thanks Mattias.  I can take a stab at a new version of the API
> today, so that we can discuss it in concrete terms.
>
> Sounds good to have the prefs API be the one and only way stuff
> outside of chrome/browser/prefs should use prefs.  I think it's very
> positive to do this.
>
> Just so that I communicate clearly though:  I'm not signing myself or
> the Browser Components team up to switch every piece of code in Chrome
> over to the new API immediately.  We will switch over code within the
> Browser Components we are extracting, as we work on them.  This should
> by the time we're done be a very large percentage of the code base but
> there may still be some code remaining that we haven't touched.
>
> To help avoid new uses that bypass the API, the new "temporarily
> allowed DEPS rules" feature can be used (see the docstring in
> tools/checkdeps/checkdeps.py) to disallow code under chrome/browser
> from using chrome/browser/prefs (but temporarily allow the existing
> usages).  I'm happy to help get this set up if you like.
>
> Cheers,
> Jói
>
>
> On Fri, Aug 17, 2012 at 8:14 AM, Mattias Nissler <[email protected]>
wrote:
>>
>>
>> On Fri, Aug 17, 2012 at 12:23 AM, Jói Sigurðsson <[email protected]> wrote:
>>>
>>> Thanks for the feedback, Bernhard and Mattias.
>>>
>>> From the quick look I took earlier today, it seemed most of the
>>> callers are either using FindPreference to check for its existence
>>> (i.e. they are doing a NULL check) or to retrieve its value, or to
>>> check whether it has its default value, all of which is or could be
>>> made available through the pref name-based methods.
>>>
>>> However, it seems from your comments that exposing Preference would be
>>> the more natural API.  I think this is perfectly doable, and I think
>>> it's OK to leave in the convenience functions.  However, one caveat I
>>> can think of is whether you want to expose in the API that there are
>>> separate stores for default values vs. user-specified values?
>>
>>
>> I'm not sure what you mean by "expose". If you refer to the existence of
>> GetDefaultValue() and GetUserPrefValue(), then yes, we want that. But that's
>> more on a semantic level: We expose that there are different logical origins
>> for values, but how we store them is still opaque.
>>
>>>
>>> This
>>> ties the hands of the implementation a little bit since then any
>>> implementation would have to separate them the same way.  Might be OK,
>>> but it's a concern for the API and I had left this out in the version
>>> I uploaded.  If we expose all of the public interface of Preference,
>>> then this idea would also be exposed.
>>>
>>> >> I don't think it's a good idea to have a blessed API, and then have a
>>> >> second thing you can use if you're in the right subdirectory. I thought
>>> >> one
>>> >> of the goals of the browser API project is to actually create a sane
>>> >> API?
>>> >> IMHO it would be better to make a good decision and then migrate
>>> >> everybody
>>> >> to that.
>>>
>>> This might be true for most users of prefs.  However, in general:  We
>>> want to create a sane API, and we want to switch all code that
>>> eventually should be a Browser Component to using the API.  On the
>>> other hand, there is code that we don't expect to be a consumer of
>>> APIs, but more like a provider of them, and since the API will never
>>> expose all of the subtleties of the underlying implementation, there
>>> may be cases where it is better for the implementation to keep talking
>>> in concrete terms so that the APIs can be left simple rather than
>>> introducing more and more functionality to them that is only used as
>>> an implementation detail.  Because of this doubt, at least for now, I
>>> don't think it should be an explicit goal to switch _everybody_ over
>>> to using each new API we define, but for sure anything that is going
>>> to become a Browser Component will eventually be switched over, and is
>>> OK to switch over as early as anybody wants to do it (as a team, we're
>>> going more component-by-component so e.g. I'm working on Autofill and
>>> defining the prefs API and will switch Autofill over, but probably
>>> leave a bunch of other destined-to-be-Browser-Components code over
>>> later, as we get to those components).
>>
>>
>> Simple answer here: Everything in chrome/browser/prefs is in the bucket of
>> "provider" code. Everybody else is consumer (except maybe for PrefService
>> construction, but that's an edge case), including code below chrome/ that's
>> not going to be a browser component. No matter whether component or not, it
>> should use one public PrefService API (and I expect that'll be the one we're
>> just deciding on).
>>
>>>
>>> Cheers,
>>> Jói
>>>
>>>
>>> On Thu, Aug 16, 2012 at 6:47 PM, Bernhard Bauer <[email protected]>
>>> wrote:
>>> > I also that feel PrefService::Preference is a part of the API, and the
>>> > methods in PrefService are convenience methods that use that API. That
>>> > being
>>> > said, we should probably look at the callers. If they only use
>>> > Preference to
>>> > check whether a preference is registered, maybe it would make sense to
>>> > get
>>> > rid of Preference completely and just store a map from pref name to
>>> > type.
>>> >
>>> > On Thu, Aug 16, 2012 at 8:07 PM, Mattias Nissler <[email protected]>
>>> > wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Thu, Aug 16, 2012 at 6:59 PM, <[email protected]> wrote:
>>> >>>>
>>> >>>> You could indeed make a GetValue() function on PrefService (it's OK
>>> >>>> to
>>> >>>> expose
>>> >>>> that), and then call that from Preference::GetValue(). Then again, I
>>> >>>> would
>>> >>>> consider PrefService::Preference to be part of the generic interface
>>> >>>> actually,
>>> >>>> so I'd feel better if that piece would move to PrefServiceBase as
>>> >>>> well.
>>> >>>
>>> >>>
>>> >>> To me, if we expose PrefService::Preference, we kind of double the API
>>> >>> surface,
>>> >>> since it has a lot of the same stuff you can get via what I currently
>>> >>> put
>>> >>> into
>>> >>> PrefServiceBase; it kind of seems like it should be one or the other.
>>> >>> I
>>> >>> think
>>> >>> it feels like an implementation detail primarily.
>>> >>
>>> >>
>>> >> It's true that there is some duplication at the moment. I think the
>>> >> original deal was that you'd use PrefService::Preference to find
>>> >> information
>>> >> about the preference other than the value. People have added
>>> >> convenience
>>> >> helpers to PrefService over time.
>>> >>
>>> >>>
>>> >>> I looked for usages of FindPreference and a large portion of them seem
>>> >>> to
>>> >>> be
>>> >>> just checking for NULL, so would be served by exposing a method to
>>> >>> check
>>> >>> for
>>> >>> that.  The rest seem like they could be implemented in other terms if
>>> >>> needed -
>>> >>> but then again there is no need to change the implementation for stuff
>>> >>> that will
>>> >>> not become a component.
>>> >>
>>> >>
>>> >> I don't think it's a good idea to have a blessed API, and then have a
>>> >> second thing you can use if you're in the right subdirectory. I thought
>>> >> one
>>> >> of the goals of the browser API project is to actually create a sane
>>> >> API?
>>> >> IMHO it would be better to make a good decision and then migrate
>>> >> everybody
>>> >> to that.
>>> >>
>>> >>>
>>> >>>
>>> >>> Finally, there is some added difficulty including Preference in
>>> >>> chrome/browser/api because it has a concrete dependency on
>>> >>> PrefValueStore
>>> >>> that
>>> >>> would then need to be broken, etc., but this shouldn't be a large
>>> >>> factor;
>>> >>> we
>>> >>> should choose what we think is the best API and implement that.
>>> >
>>> >
>>> > I would have assumed if we move Preference to api/ that we'd create an
>>> > interface class like for PrefService. The implementation of that
>>> > interface
>>> > can then depend on PrefValueStore.
>>> >
>>> >>
>>> >> That's an implementation detail that shouldn't guide our decision on
>>> >> how
>>> >> we would like the API to look like too much.
>>> >>
>>> >>> Let me know what you think about the points I make above.  I'm not the
>>> >>> expert on
>>> >>> this code, you are.  My opinions may be colored by the fact that the
>>> >>> shortest
>>> >>> path to completing my current patch seems to be to add the GetValue
>>> >>> accessor to
>>> >>> PrefServiceBase and call it a day :)
>>> >>
>>> >>
>>> >> I understand that :) If you want to do that for now, I'm not going to
>>> >> object. I'll need to think more about what the preferred API would be
>>> >> from
>>> >> my point of view. Also adding the other chrome/browser/prefs
>>> >> maintainers in
>>> >> case they have an idea.
>>> >>
>>> >>>
>>> >>>
>>> >>> Cheers,
>>> >>> Jói
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 2012/08/16 16:48:33, Mattias Nissler wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>>> >>>>
>>> >>>> File chrome/browser/api/prefs/pref_member.cc (right):
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>>
http://codereview.chromium.org/10828345/diff/1/chrome/browser/api/prefs/pref_...
>>> >>>>
>>> >>>> chrome/browser/api/prefs/pref_member.cc:75:
>>> >>>> prefs_->GetUserPrefValue(pref_name_.c_str())->DeepCopy(),
>>> >>>> On 2012/08/16 15:34:18, Jói wrote:
>>> >>>> > On 2012/08/16 15:16:42, Mattias Nissler wrote:
>>> >>>> > > also incorrect
>>> >>>> >
>>> >>>> > This, and the thing above, was me trying to get rid of
>>> >>>> > FindPreference
>>> >>>> > from
>>> >>>
>>> >>> the
>>> >>>>
>>> >>>> > base API.  I misread the GetUserPrefValue documentation, and I see
>>> >>>> > now
>>> >>>> > that
>>> >>>> this
>>> >>>> > is not equivalent.
>>> >>>> >
>>> >>>> > I wonder if I should instead simply add GetPrefValue(name) which
>>> >>>> > returns a
>>> >>>> > base::Value* like these two guys, but basically just does
>>> >>>> > FindPreference(name)->GetValue().  I think that would make both
>>> >>>> > places
>>> >>>> > equivalent, although the DCHECK at the top would be checking a
>>> >>>> > different
>>> >>>
>>> >>> thing
>>> >>>>
>>> >>>> > it should be semantically the same?
>>> >>>
>>> >>>
>>> >>>> You could indeed make a GetValue() function on PrefService (it's OK
>>> >>>> to
>>> >>>> expose
>>> >>>> that), and then call that from Preference::GetValue(). Then again, I
>>> >>>> would
>>> >>>> consider PrefService::Preference to be part of the generic interface
>>> >>>> actually,
>>> >>>> so I'd feel better if that piece would move to PrefServiceBase as
>>> >>>> well.
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> http://codereview.chromium.org/10828345/
>>> >>
>>> >>
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "browser-components-watch" group.
>>> > To post to this group, send email to
>>> > [email protected].
>>> > To unsubscribe from this group, send email to
>>> > [email protected].
>>> > For more options, visit
>>> > https://groups.google.com/a/chromium.org/groups/opt_out.
>>> >
>>> >
>>
>>

[Jói, 2012-08-17 17:03:10]

Mattias:  Patchset 2 adds the Preference class and the FindPreference method to
the API, in what I think is probably the simplest way possible.

I would love to be able to land like this to resolve the Autofill dependency and
have a nice end to my week :)

As a follow-up (perhaps from your side once you have had design discussions),
the interface could be split into syncable vs. local pref stores.  I think the
simplest approach for refining the API for this (and I mean simplest in terms of
"a sensible API that won't be too hard to switch callers to) might be to split
it up roughly like this:
- Have a top-level PrefMap interface that has the Preference class and the
Get/Set/Find/Subscribe-to-changes functionalities.
- Have an interface, LocalPrefRegistry or LocalPrefService that inherits from
PrefMap, adds all the non-syncable registration/unregistration methods, and a
static ForProfile() method to get the instance of this for a given profile.
- Have a similar interface, SyncablePrefRegistry or SyncablePrefService that has
the syncable registration methods instead.

For now, PrefService would inherit from both LocalPrefRegistry and
SyncablePrefRegistry, but down the road these could be separate but related
implementations.

Let me know what you think, and whether I am good to land the patch with the API
in its current state.

Cheers,
Jói

[Mattias Nissler (ping if slow), 2012-08-17 17:21:52]

The API looks sane to me, so you have my LGTM for chrome/browser/{prefs,policy}.

Regarding the PrefService vs. Sync refactoring, your proposal is workable I
think. Another idea I'm pondering is putting the registration logic into a
separate class/interface called PrefRegistry which the base implementation for
PrefService could then use to check for pref names and defaults. The sync
variant could then just derive from the base implementation and use a different
PrefRegistry implementation that keeps the sync flags in addition to name and
default value.

[Jói, 2012-08-17 17:26:07]

Right, that would be another way.  You could fully decouple the
registration interfaces from the access (read/write/find/subscribe)
interface, but in a service interface have a way to get both of these
for a given pref service.

Thanks for the review.

Cheers,
Jói


On Fri, Aug 17, 2012 at 5:21 PM,  <[email protected]> wrote:
> The API looks sane to me, so you have my LGTM for
> chrome/browser/{prefs,policy}.
>
> Regarding the PrefService vs. Sync refactoring, your proposal is workable I
> think. Another idea I'm pondering is putting the registration logic into a
> separate class/interface called PrefRegistry which the base implementation
> for
> PrefService could then use to check for pref names and defaults. The sync
> variant could then just derive from the base implementation and use a
> different
> PrefRegistry implementation that keeps the sync flags in addition to name
> and
> default value.
>
> http://codereview.chromium.org/10828345/

[erikwright (departed), 2012-08-20 05:32:15]

LGTM.

[commit-bot: I haz the power, 2012-08-21 12:06:11]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/10828345/11004

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

Change committed as 152569

[battre, 2012-10-15 12:44:37]

On 2012/08/21 16:28:23, I haz the power (commit-bot) wrote:
> Change committed as 152569

I have seen this CL from a long, long time ago. Shouldn't we rename
PrefServiceBase to PrefService and the current PrefService to PrefServiceImpl?

Is there still a plan to have a SyncablePrefServiceBase? The pref_service_base.h
file refers to it but codesearch does not find it.

The current design looks incomplete to me.

Best regards,
Dominic

[tfarina, 2012-10-15 12:46:59]

On Mon, Oct 15, 2012 at 9:44 AM,  <[email protected]> wrote:
> On 2012/08/21 16:28:23, I haz the power (commit-bot) wrote:
>>
>> Change committed as 152569
>
>
> I have seen this CL from a long, long time ago. Shouldn't we rename
> PrefServiceBase to PrefService and the current PrefService to
> PrefServiceImpl?
>
Yeah, I suggested that when the patch came in.

I don't recall what was Joi's justification to go with PrefServiceBase though.

-- 
Thiago

[Jói, 2012-10-15 13:01:12]

We are moving Prefs out of Chrome and PrefServiceBase will likely go
away after the move is complete.  I am looping you into the thread
that's been going on with mnissler@ and bauerb@ about that.

As part of those changes, the plan is to look at splitting off the
sync part of PrefService.

The reasons a rename wasn't done at the time were:
a) It wasn't clear whether we would change all code to use the API,
especially in the short term;
b) If not all code would switch to the API, I wasn't sure whether it
was good to make most Chrome developers learn a new name
(PrefServiceImpl);
c) Part of the reason was simply wanting to defer large-scale renames
until upstreaming (Clank & Bling) was further along.

The idea was that the rename could be done at any time and would be
done once it was clear that the top class would better be named
PrefService, rather than e.g. PrefServiceBase or PrefServiceAPI.
Anyway, at this point it is moot.

Cheers,
Jói



On Mon, Oct 15, 2012 at 12:46 PM, Thiago Farina <[email protected]> wrote:
> On Mon, Oct 15, 2012 at 9:44 AM,  <[email protected]> wrote:
>> On 2012/08/21 16:28:23, I haz the power (commit-bot) wrote:
>>>
>>> Change committed as 152569
>>
>>
>> I have seen this CL from a long, long time ago. Shouldn't we rename
>> PrefServiceBase to PrefService and the current PrefService to
>> PrefServiceImpl?
>>
> Yeah, I suggested that when the patch came in.
>
> I don't recall what was Joi's justification to go with PrefServiceBase
though.
>
> --
> Thiago