Re: [gdome]reference counts and freeDoc (fwd)

[Luca Padovani <lpadovan cs unibo it>]

Again on ref counting and memory management.

I think that, at least at present, the different memory management
adopted in gdome2 (think of gdome_di_freeDoc) makes sense in a language
without garbage collector as C++ and in a language with g.c. as ruby,
though, in the second case, the user is required to manage the
allocation of the whole document explicitly. The point is that if a more
uniform interface is adopted (where gdome_doc_unref behaves like all the
other unrefs), in a g.c. language the user is then forced to keep a live
reference to the document, to prevent the whole document to be freed
while one has a live reference to an inner node. And this is in
contrast with the policy of garbage collecting, because in principle the
whole document is accessible by means of any inner reference.
Even worse, this is also wrong is the context of a functional language,
because one is required to retain somewhere a reference to the document
(very imperative).

Due to the wrapping mechanism of gdome, we cannot enforce a clean
ref-counting among nodes (parent-child, siblings), so I see just two
solutions:
* the first one is to keep a non-uniform interface and a specific method
for freeing the document (this is the current state, more or less).
* the second is the trick given by Tobias Peters, allowing for
uniformity:

> How about that (modified 2.): All existing node objects also increase the
> reference count of the doc object, and unref it on destruction. When doc's
> refcount reaches zero, free the document. This way, doc is guaranteed to
> be the last node alive, and when it dies, the libxml tree should go with
> it.

This approach works fine, in the sense described above, but I cannot
consider it much more than a trick.

So, this problem needs to be solved, eventually. Have you got any
preferences?

Cheers,

	luca