Add AbstractFieldDetails.id to identify instances of details.

This will unify the way we handle IDs for the various classes that
derive from AbstractFieldDetails for eccentric data stores (I'm
looking at you, Tracker).

Helps: bgo#662433 - AbstractFieldDetails.equal() is ambiguous about
checking parameters.

diff --git a/NEWS b/NEWS
index 96eff08..5b95fcc 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -3,6 +3,9 @@ Overview of changes from libfolks 0.6.4.1 to libfolks 0.6.5
 Bugs fixed:
 * Bug 662285 — Error with email -> im_addresses when updating a contact
 
+API changes:
+* Add AbstractFieldDetails.id to identify instances of details
+
 Overview of changes from libfolks 0.6.4 to libfolks 0.6.4.1
 =============================================================
 Bugs fixed:

diff --git a/folks/abstract-field-details.vala b/folks/abstract-field-details.vala
index e36a8da..c89e762 100644 (file)
--- a/folks/abstract-field-details.vala
+++ b/folks/abstract-field-details.vala
@@ -101,6 +101,25 @@ public abstract class Folks.AbstractFieldDetails<T> : Object
       set { this._value = value; }
     }
 
+  private string _id;
+  /**
+   * A unique ID (if any) for this specific detail.
+   *
+   * This is primarily intended for {@link PersonaStore}s which need to track
+   * specific instances of details (because their backing store is wacky).
+   *
+   * In most cases, this will be an empty string.
+   *
+   * The content of this is opaque to all but the package which set it.
+   *
+   * @since UNRELEASED
+   */
+  public virtual string id
+    {
+      get { return this._id; }
+      set { this._id = (value != null ? value : ""); }
+    }
+
   private MultiMap<string, string> _parameters =
       new HashMultiMap<string, string> ();
   /**