Introduce //components/user_prefs, use to eliminate c/b/prefs dependency in Autofill.

components/user_prefs/user_prefs.h

Index: components/user_prefs/user_prefs.h
diff --git a/components/user_prefs/user_prefs.h b/components/user_prefs/user_prefs.h
new file mode 100644
index 0000000000000000000000000000000000000000..a47d058d08f54b6b03452728efe730e131589bdf
--- /dev/null
+++ b/components/user_prefs/user_prefs.h
@@ -0,0 +1,60 @@
+// Copyright 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef COMPONENTS_USER_PREFS_USER_PREFS_H_
+#define COMPONENTS_USER_PREFS_USER_PREFS_H_
+
+#include "base/basictypes.h"
+#include "base/memory/scoped_ptr.h"
+#include "components/user_prefs/user_prefs_delegate.h"
+#include "components/user_prefs/user_prefs_export.h"
+
+template <typename T> struct DefaultSingletonTraits;
+class PrefService;
+
+namespace content {
+class BrowserContext;
+};

[Elliot Glaysher, 2013/02/28 21:13:18]

The dependency on content isn't reflected in the gyp file.

[tfarina, 2013/02/28 21:40:49]

it isn't necessary to list content.gyp:content_browser because only a pointer is
passed but no use is made actually. i.e., we don't have any context->Foo() that
would require us to link with the content library.

[Jói, 2013/02/28 21:46:00]

What Thiago said :)

[Elliot Glaysher, 2013/02/28 21:47:24]

I'm aware that we aren't dereferencing the type, however, we're still
referencing a type from a deeper layer here.

+
+namespace components {
+
+// Components may use preferences associated with a given user. These
+// are retrieved based on content::BrowserContext.
+//
+// This singleton is initialized by embedders, to provide other
+// components with a means of doing this lookup.
+class USER_PREFS_EXPORT UserPrefs {
+ public:
+  // Retrieve the singleton UserPrefs.
+  static UserPrefs* GetInstance();
+
+  // This is shorthand for GetInstance()->Lookup(context).
+  static PrefService* Get(content::BrowserContext* context);
+
+  ~UserPrefs();
+
+  // Returns true iff |Initialize| has been called.
+  bool IsInitialized() const;
+
+  // Must be called exactly once, before any other method calls on
+  // this object. This object takes ownership of the delegate.
+  void Initialize(scoped_ptr<UserPrefsDelegate> delegate);

[Elliot Glaysher, 2013/02/28 21:13:18]

I'd be a lot more comfortable with the UserPrefs if the delegate weren't a
singleton, but was instead a mapping from BrowserContext to delegate or
BrowserContext to PrefService.

[Jói, 2013/02/28 21:46:00]

I'm not exactly sure what you mean.  UserPrefs is a way to map from
BrowserContext to PrefService, in an embedder-specific way.  The singleton is
not exactly stateful; it just has a pointer to the single, embedder-provided
implementation of the delegate.  This is analogous to how ContentClient and its
ilk are done.

[Elliot Glaysher, 2013/02/28 21:58:57]

What I'm asking is how likely is it that non-chrome/ things like apps will want
to inject their own logic for mapping a BrowserContext to a PrefService.

+
+  // Retrieves the PrefService for the user preferences tied to the
+  // given BrowserContext. Returns NULL if there is no such
+  // PrefService, or if |Initialize| has not been called.
+  PrefService* Lookup(content::BrowserContext* context);
+
+ private:
+  UserPrefs();
+  friend struct DefaultSingletonTraits<UserPrefs>;
+
+  scoped_ptr<UserPrefsDelegate> delegate_;
+
+  DISALLOW_COPY_AND_ASSIGN(UserPrefs);
+};
+
+}  // namespace components
+
+#endif  // COMPONENTS_USER_PREFS_USER_PREFS_H_