Re: GHashTable suggestions

[Darin Adler <darin eazel com>]

on 1/5/01 10:52 AM, Havoc Pennington at hp redhat com wrote:

>> 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. ;-)

I think you are overstating the case.

I don't see that this makes g_hash_table_insert more difficult to explain
than it already is. This is 100% consistent with how it is now, and it's not
so complicated to explain:

    Creates a new hash table entry with the passed key and value. If there's
already a hash table entry, destroys the passed key, and replaces the old
value with the new one, destroying the old value.

But adding a new g_hash_table_replace would also be fine with me.

    -- Darin