GNOME Bugzilla – Bug 569620
Extend boxed types to have hash and equal methods
Last modified: 2018-05-24 11:44:02 UTC
Boxed types are commonly used to wrap "value" types. Value types are those typically copied by value instead of being refcounted. A very common operation with value types is to hash them. To hash them one needs hash and equal methods. If GBoxed is extended to take hash and equal functions, language bindings get the correct hash and equal functions automatically. Currently the binding writer needs to manually hook up the hash and equal functions. I'm proposing: GType g_boxed_type_register_static_full (const gchar *name, GBoxedCopyFunc boxed_copy, GBoxedFreeFunc boxed_free, GHashFunc boxed_hash, GEqualFunc boxed_equal); guint g_boxed_hash (GType boxed_type, gconstpointer boxed); gboolean g_boxed_equal (GType boxed_type, gconstpointer boxed_a gconstpointer boxed_b); If the hash and/or equal functions are not provided, direct hash/equal are used.
I have no opinion on the usefulness of this. I suspect bindings coders have a better idea if it's useful to them. In C, it's useless I guess. But if we add it, it'd probably better as: g_boxed_type_add_hash_functions (GType boxed_type, GHashFunc boxed_hash, GEqualFunc boxed_equal); That's clearer as it gets around the _full() moniker and allows for future extensibility.
Ping?
See also bug 678619 for improving the boxed type API. Making it easier to add hash and equal functions makes sense to me.
There are a few places in the Python bindings where we override the __eq__ operator with functions like gdk_color_equal. This would be a welcome addition to help clean that up because it could be done generically (and correctly) for all boxed types (I think the default is a pointer comparison). Likewise, Pythons __hash__ could be set to use g_boxed_hash for more effective usage of boxed types as dictionary keys or in sets.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/193.