Re: GHashTable suggestions

[Havoc Pennington <hp redhat com>]

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:

 if (foo)
   it does X
 else if (bar)
   it does Y
 else
   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. ;-)

Havoc