[05:07] <sadmac> Keybuk: thought: nih_discard should run the destructor always.
[09:39] <Keybuk> sadmac: why?
[14:17] <sadmac2> Keybuk: Think of it in the case of our most common destructor: removing the node from a list. Discard should only leave the item around for people still referencing it, which means external references like that should go away.
[14:37] <Keybuk> right, but that's not how it's supposed to work ;-)
[14:37] <Keybuk> discard is "drop the NULL reference"
[14:38] <Keybuk> the assumption is that you allocate an object with a NULL reference, pass it to something that actually references it
[14:38] <Keybuk> and then drop the NULL ref
[14:38] <Keybuk> if it didn't get referenced, dropping the NULL ref does free it
[14:38] <Keybuk> e.g.
[14:38] <Keybuk> void *foo;
[14:38] <Keybuk> foo = nih_new (NULL, SomeObject);
[14:39] <Keybuk> nih_list_init (&foo->entry);
[14:39] <Keybuk> pass_to_some_func (foo);
[14:39] <Keybuk> nih_discard (foo);
[14:39] <Keybuk> ...
[14:39] <Keybuk> where
[14:39] <Keybuk> pass_to_some_func (void *foo)
[14:39] <Keybuk> {
[14:39] <Keybuk>     nih_list_add (&foos, &foo->entry);
[14:39] <Keybuk>     nih_ref (foo, &foos);
[14:39] <Keybuk> }
[14:41] <sadmac2> well that's what it /does/ sure :) The name to me implies "normal operation of the program is done with this object. Only keep it around if something hasn't remembered to dereference it yet."
[14:42] <sadmac2> In a more literal sense, "discarding" the object should take it out of a list.
[14:42] <Keybuk> it's more equivalent to g_ref_sink in the old libgtk style referencing
[14:44] <sadmac2> Keybuk: also I've occasionally found a list that I'd prefer used internal referencing (i.e. actually do nih_ref (list, list->next) etc rather than just having a destructor pull it out when its done). I was thinking of adding a second set of list helpers to facilitate maintaining a list in this way.
[14:45] <Keybuk> sure, that's more like how nih_list_entry works, no?
[14:45] <sadmac2> hm?
[14:45]  * sadmac2 pulls a libnih tree onto his work machine
[14:47] <Keybuk> NihList is embedded in structures
[14:47] <Keybuk> NihListEntry is an NihList with a generic pointer
[14:47] <Keybuk> where the list references the data contained in it
[14:48] <sadmac2> oic. that's an interesting way of doing it...
[14:48] <sadmac2> does its destructor unreference its target pointer then?
[14:48] <Keybuk> you could make it do that
[14:50] <sadmac2> then you could just use nih_free on the entry to remove from the list
[14:50] <Keybuk> in theory the list/alloc stuff should be flexible enough to do it either way
[14:51] <Keybuk> one of my other two libnih-using projects doesn't use the embedded list stuff
[14:51] <Keybuk> because every object is in multiple lists
[14:52] <sadmac2> I've also had some ideas I'm sitting on about how to reduce nih_alloc's overhead and possibly make it a bit more flexible, but I'm still churning.
[14:56] <sadmac2> I have a thought that we could kill the parent/child lists and store a big adjacency matrix instead within a good sparse matrix data structure
[14:57] <sadmac2> might perform better too (cache lines hate linked lists)