Re: GHashTable suggestions
- From: Havoc Pennington <hp redhat com>
- To: Darin Adler <darin eazel com>
- Cc: Sven Neumann <sven gimp org>, <gtk-devel-list gnome org>
- Subject: Re: GHashTable suggestions
- Date: 05 Jan 2001 13:52:38 -0500
Darin Adler <darin eazel com> writes:
> on 1/5/01 7:57 AM, Havoc Pennington at hp redhat com wrote:
> >> The only problem I see is that inserting a new item into a GHashTable
> >> does replace the value (and destroys it if a destroy_func was given),
> >> but keeps the old key in place. This problem is longstanding, but
> >> should probably be handled differently when a key_destroy_func is
> >> specified ?!
> > Maybe we could add g_hash_table_replace() which is like _insert() but
> > replaces the key? Kinda lame, but also kinda needed... dunno.
> It seems to me that destroying the new key passed in instead of the one in
> the hash table in this case would be fine (and compatible), although I
> wouldn't design a new class this way. We wouldn't need a new
> g_hash_table_xxx call. I can't think of any case where this would cause
> trouble in code that I write; callers who don't want this behavior can do
> g_hash_table_remove followed by g_hash_table_insert instead.
I'm just reluctant to make g_hash_table_insert() even more difficult
to explain than it already is... I don't like function docs like:
it does X
else if (bar)
it does Y
it does Z
This rapidly results in bug infestations...
Of course, explaining the difference between _insert() and _replace()
would also require some confusing docs, and is some API bloat.
The cleanest solution to me is to make _replace() always replace the
key, freeing if there's a dnotify, and then you can sort of ignore
_insert() unless you know about its weird behavior.
Blah. This is why one wants to get the API right the first time. ;-)
] [Thread Prev