Remove PrefServiceSimple, replacing it with PrefService and PrefRegistrySimple.

chrome/browser/prefs/pref_registry.cc

+// Copyright (c) 2012 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.
+
+#include "chrome/browser/prefs/pref_registry.h"
+
+#include "chrome/browser/prefs/pref_service.h"
+
+PrefRegistry::PrefRegistry()
+    : pref_service_(NULL),
+      default_prefs_(new DefaultPrefStore()) {
+}
+
+void PrefRegistry::DeprecatedUnregisterPreference(const char* path) {
+  DCHECK(pref_service_);
+  if (pref_service_)
+    pref_service_->UnregisterPreference(path);

[Mattias Nissler (ping if slow), 2013/01/25 14:57:11]

I'd rather not call into pref_service and back. Given that
PrefService::UnregisterPreference() is meant to go away eventually, how about
letting consumers call that function instead and have it call
PrefRegistry::UnregisterPreference()?

That way, we should be able to remove the |pref_service_| pointer here entirely
(which would make the design much cleaner in that PrefRegistry is now a true
dependency of PrefService and we don't have inverse arrows).

[Jói, 2013/01/29 16:10:02]

This needs to stay here (and be virtual) since PrefServiceSyncable will do more
than just unregister from the DefaultPrefStore.  In any case, registration is
now entirely in PrefRegistry.

+}
+
+void PrefRegistry::RetrieveDefaults(scoped_refptr<DefaultPrefStore>* result) {
+  result->swap(default_prefs_);  // This releases the member reference.

[Mattias Nissler (ping if slow), 2013/01/25 14:57:11]

Why would we want to release the pointer here?

[Jói, 2013/01/29 16:10:02]

This was meant as a belt-and-suspenders approach to ensure no registrations
after construction of the PrefService, unless they go to PrefService.  The new
approach is much nicer.

+}
+
+void PrefRegistry::RegisterPreference(const char* path,
+                                      base::Value* default_value) {
+  if (pref_service_) {
+    pref_service_->RegisterPreference(path, default_value, false);
+  } else {
+    default_prefs_->SetDefaultValue(path, default_value);
+  }

[Mattias Nissler (ping if slow), 2013/01/25 14:57:11]

It seems like instead of sometimes delegating to PrefService, we should rather
move the entire logic over to PrefRegistry (including the RegisterXYZPref calls
eventually).

[Jói, 2013/01/29 16:10:02]

Done, but PrefService still gets callbacks to update its internal state.

+}