Re: GHashTable improvements
- From: Tim Janik <timj gtk org>
- To: Darin Adler <darin eazel com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, sven gimp org, Owen Taylor <otaylor redhat com>
- Subject: Re: GHashTable improvements
- Date: Sat, 17 Mar 2001 00:18:40 +0100 (CET)
On Fri, 16 Mar 2001, Darin Adler wrote:
> on 3/16/01 3:03 PM, Tim Janik at timj gtk org wrote:
>
> >> - In the discussion earlier, there was some idea that g_hash_table_replace()
> >> wasn't necessary as long as g_hash_table_insert() called the destroy
> >> notify on the key function.
> >
> > that would change the documented semantics of g_hash_table_insert() in a way
> > that's very hard to debug. we had this discussion (on gnome-hackers iirc)
> > during
> > pre-1.2 and didn't change it back then either.
> > so g_hash_table_insert() should stay as it is, i.e. not touching node->key if
> > it's used to replace items, even if that justifies another API call
> > g_hash_table_replace(). at least with that, we can tell people to use
> > g_hash_table_replace() if they want to replace instead of insert.
> > the replacement bahviour for _insert() just needs to be properly explained
> > in the official docs and that's it.
>
> I think you're missing one detail of the proposal, Tim. To preserve the old
> semantics, the key that's destroyed in the case of g_hash_table_insert over
> an existing hash table entry is the one passed in.
doh! erk. thanks for pointing this out.
at that point though, i wonder if it actually matters _what_ key is destroyed
if destroy notifiers are used.
it'd probably only matter if people start peeking keys back with some
_no_notify() variant, hard to guess which one they'd expect to remain
valid. heck this gets ugly!
>
> -- Darin
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]