GNOME Bugzilla – Bug 589801
Adding Pair, Tripple and some implementations
Last modified: 2010-07-14 09:37:16 UTC
Adding pair to libgee would have following advantages: - It would make Gee.Map iterable in full sense (both values and keys at the same time). On top of such iteration key and set iterations can be easily abstracted. it would also allowed to have mutating interfaces for Gee.Map as in bug 589800 - It would allow to base Gee.Map on Gee.Set i.e. having underlying Gee.Set<Gee.Pair<K,V>> shortening the code
I would prefer to have a specific Map.Entry interface for the entries of maps. This Entry interface would have key and value properties. In constrast to that, it is still interesting for some people to have a Pair class. Here are some things Pair could provide (comments by Michael Lauer copy/pasted from Vala's ML): - Equality tests (pairs and tuples), - Swapping elements (pairs), - Adding from/to other (pairs, tuples), - Slicing into other, - Converting to/from string.
(In reply to comment #1) > I would prefer to have a specific Map.Entry interface for the entries of maps. > This Entry interface would have key and value properties. > I'll try to experiment with it.
I add dependency to bug 557719. I considered several scenarios: Adding Map.Entry as an interface: - Cannot be simply used to modifing underlying map - Rather slow (most current Map.Entries are based on compact classes) Adding Map.Entry as an class: - Needs to be virtual/GObject anyway to not break ReadOnlyMap readonlyness. Adding Map.MutableEntry as subclass of Map.Entry: - Needs split between map and mutable map
Created attachment 140682 [details] [review] 0001-Added-basic-Map.Entry.patch Share of work. Patch *not* finished. Depends on bug 591718 (for contains).
Created attachment 140686 [details] [review] 0001-Added-Map.Entry.patch A nearly working patch. The only remaining problems: - How to map equalities and hashes - How to prevent modification
Personally from the current point I see two ways: - Full closures support within vala without additional parameter (unlikely but I know too little about vala and gcc C extention to state this for sure). - Other implementation of closures (possibly using llvm). Cons: lots of code having nothing to do with collections - Change API to handle equality etc. on values. Cons: Breaks API. Very unhandy - Implementing Set based on Map rather then other way round (Set<T> as Map<T,void>). Cons: vala don't have void. Also it takes more space (additional pointer) - Resign. Cons: Lots of duplicate code betwean Map and Set.
PS. I'm personally for full closures support or implementing set based on map.
Ups. - Change API to handle additional parameter in which user data is passed. Cons: breaks API
commit 93ab6ba6e32056ef9f15ff8ce844143c207c99b6 Author: Didier 'Ptitjes <ptitjes@free.fr> Date: Sun Sep 20 16:25:17 2009 +0200 Introduce the Map.Entry<K,V> class and the Map.entries property We also use Map.entries to optimize the implementations of set_all, has_all and HashMultiMap by avoiding the common pattern: iterate on keys and for each key get the associated value. This fixes part of this bug, so let me change the summary of this ticket.
*** This bug has been marked as a duplicate of bug 531918 ***