Greetings. On 2010 Mar 8, at 22:13, Norman Gray wrote:
> * If not, does this sound like a plausible enhancement request? It would > suit _me_ very well if closing the storage object simply blew away the > un-emptied iterator objects, rather than objecting to them. Also, the > storage object isn't documented as holding on to the iterator objects that > are related to it, so I wouldn't have been able to know to avoid this from > the API docs. Thinking about this a little more, it sounds as if a plausible change (from the application developer point of view) would be to separate out nullification of an object from deallocation of the memory. Thus nullification would be an idempotent operation which clears the state of the object and nullifies any dependent objects. The librdf_free_* functions could consist of nullification followed by deallocation. In the case I mentioned, I can imagine librdf_free_storage nullifying the storage by clearing its state, in some appropriate fashion, then nullifying each of the iterator objects it (secretly) holds on to, then the storage object, but not the iterator objects, being deallocated. Nullification of an iterator (in this example) would discard any remaining objects, but not deallocate the iterator. It would be possible to hold onto and call a nullified object (because it hasn't been deallocated), but it would report there being no further objects to return, and therefore no remaining dependence on the storage object. I think this is better than producing an error on access to a nullified object. I haven't looked at the code, but I suspect this would be a repetitive but fairly mechanical addition to the implementation. I don't believe there would be any need to add the nullification functions to the exposed API. The addition would make it a lot easier to use librdf in contexts such as garbage-collected extensions where the user is otherwise released from worrying about this sort of release/reclamation ordering. Best wishes, Norman -- Norman Gray : http://nxg.me.uk _______________________________________________ redland-dev mailing list [email protected] http://lists.librdf.org/mailman/listinfo/redland-dev
