GNOME Bugzilla – Bug 646079
Unify the data structure used for properties that our collections
Last modified: 2011-07-11 23:11:19 UTC
As folks keeps growing and growing in the number of interfaces which provide attributes exposed by Personas, we are seeing a wide variety of data structures used to express attributes which are some sort of collection (urls, phones, etc). Among those types we have: - GList - GHashTable - GeeHashMap - ... Its arguable that the nature of certain properties favour one data type over the other. But trying to unify and use these types in a consistent way would allow us to refactor common code together (i.e.; methods that deal with sending/receiving properties back and forward to/from backends) and come up with useful patterns.
(In reply to comment #0) > As folks keeps growing and growing in the number of interfaces which provide > attributes exposed by Personas, we are seeing a wide variety of data structures > used to express attributes which are some sort of collection (urls, phones, > etc). > > Among those types we have: > > - GList Being replaced with LinkedHashSet (and other, more appropriate, more type-safe, types): bug #640092. > - GHashTable I think Travis and I agreed before that since we're using GeeHashMap and other libgee data structures in the public API, we might as well go all the way and replace GHashTable with GeeHashMap for consistency. Travis, is that correct? > - GeeHashMap > - ... > > Its arguable that the nature of certain properties favour one data type over > the other. But trying to unify and use these types in a consistent way would > allow us to refactor common code together (i.e.; methods that deal with > sending/receiving properties back and forward to/from backends) and come up > with useful patterns.
(In reply to comment #1) > > - GHashTable > > I think Travis and I agreed before that since we're using GeeHashMap and other > libgee data structures in the public API, we might as well go all the way and > replace GHashTable with GeeHashMap for consistency. > > Travis, is that correct? GeeHashMap is a little more work to use from C, but it's worth it on the balance.
See bug #640092 for a branch which should do all of this. I guess this bug could either be closed, or remain open to track refactoring code which touches common types (like Set<string> and Set<FieldDetails>).
(In reply to comment #3) > See bug #640092 for a branch which should do all of this. I guess this bug > could either be closed, or remain open to track refactoring code which touches > common types (like Set<string> and Set<FieldDetails>). Does anyone have any examples of cases where we could unify types (as of the current state of master)? If not, I think we should just close this.
(In reply to comment #4) > (In reply to comment #3) > > See bug #640092 for a branch which should do all of this. I guess this bug > > could either be closed, or remain open to track refactoring code which touches > > common types (like Set<string> and Set<FieldDetails>). > > Does anyone have any examples of cases where we could unify types (as of the > current state of master)? I don't, apart from the subclassing FieldDetails thing.
This will be fixed when bug #653682 comment #1 is implemented. *** This bug has been marked as a duplicate of bug 653682 ***