Add ComputeMac and ComputeSplitMacs methods to pref_hash_store.

components/user_prefs/tracked/pref_hash_store.h

Index: components/user_prefs/tracked/pref_hash_store.h
diff --git a/components/user_prefs/tracked/pref_hash_store.h b/components/user_prefs/tracked/pref_hash_store.h
index 2fdc617301ae1fea64526ae16fe5d6621c272406..e465a6daa502ebe0a66855cabc368512887cc7a1 100644
--- a/components/user_prefs/tracked/pref_hash_store.h
+++ b/components/user_prefs/tracked/pref_hash_store.h
@@ -7,6 +7,8 @@
 
 #include <memory>
 
+#include "base/values.h"

[gab, 2016/09/01 21:21:56]

fwd-decl instead:

namespace base {
class DictionaryValue;
class Value;
}

[proberge, 2016/09/06 18:43:38]

Done. This whole include vs fwd-decl is still very nebulous to me. Can you point
me to some documentation which explains when to include vs when to fwd-decl?

[gab, 2016/09/06 20:08:04]

The concept is known as IWUY (include-what-you-use). The idea is that every .cc
should include what it uses (i.e. not rely on included headers to do so for it
-- making refactorings easier).

There is an exception when the matching .h already has that include.

That exception extends to a .h with overrides (by recursive IWUY: includes from
the overridden interface must have been included by its header so those includes
would be redundant -- only include them if needed by non-overrides of your
class, in other words "overrides" don't count in "what you use").


Now forward-decls versus includes:

In headers you often only need to tell the compiler that the type exists (not
its full definition). This is true for example with pointers and const&.
Basically ask yourself whether the compiler needs to know the size of the object
and/or know how to construct/destroy it when parsing your .h, if not, a
forward-declaration is enough.

STL types (and templates) can't be forward declared though.


So overall, in headers: include-what-you-use (things you "use" are usually:
non-pointer members, return values and parameters passed by value) and
forward-declare-the-rest.

http://stackoverflow.com/a/17499222 is a good read on why you should include
(not fwd-decl) for return values and params passed by value -- fwd-decl is
sufficient for the definition of the method but e.g. making your users have to
include type only to have the destructor when ignoring the return value isn't
cool.

+
 class HashStoreContents;
 class PrefHashStoreTransaction;
 
@@ -23,6 +25,21 @@ class PrefHashStore {
   // related transactions should correspond to the same underlying data store.
   virtual std::unique_ptr<PrefHashStoreTransaction> BeginTransaction(
       std::unique_ptr<HashStoreContents> storage) = 0;
+
+  // Computes the MAC to be associated with |path| and |value| in this store.
+  // PrefHashStoreTransaction typically uses this internally but it's also
+  // exposed for users that want to compute MACs ahead of time for asynchronous
+  // operations.
+  virtual std::string ComputeMac(const std::string& path,

[gab, 2016/09/01 21:21:56]

#include <string>

(can't fwd-decl lib types)

[proberge, 2016/09/06 18:43:39]

Done.

+                                 const base::Value* value) = 0;
+
+  // Computes the MAC to be associated with |path| and |split_values| in this
+  // store. PrefHashStoreTransaction typically uses this internally but it's
+  // also exposed for users that want to compute MACs ahead of time for
+  // asynchronous operations.
+  virtual std::unique_ptr<base::DictionaryValue> ComputeSplitMacs(

[gab, 2016/09/06 20:08:04]

Also, based on above discussion I just realized that this and
PrefHashStoreTransaction should be includes not fwd-decls, per being return
values (not a big deal, but to be pedantic -- so back to values.h here and not
in .cc if you're with me :-)).

[proberge, 2016/09/07 18:00:56]

Done.

+      const std::string& path,
+      const base::DictionaryValue* split_values) = 0;
 };
 
 #endif  // COMPONENTS_PREFS_TRACKED_PREF_HASH_STORE_H_