Re: [Vala] libxml tree API bindings

[Jürg Billeter <j bitron ch>]

On Thu, 2007-11-08 at 17:26 +0100, Ondřej Jirman wrote:
> Hi,
>
> I've been working on updating libxml bindings with tree API. Here are
> some results and a few notes/questions.
>
> - libxml tree API naming convention/parameter passing is crazy, I had
>   to implemnt [Instance(position = number)] attribute to be able to have
>   doc.save_file_format("path") method. Patch attached.

Just using a number can become an issue as the instance parameter is not
always the only parameter that is visible in C but not in Vala, for
example array length and GError parameters also have to be inserted at
specific positions. We need to allow arbitrary positioning for array
length parameters anyway and we should integrate support for positioning
the instance parameter at the same time.

> - I have found that before the second call to func, mem will not be
>   freed:
>
>     xmlstring mem;
>     func(out mem);
>     func(out mem);
>
>   And here it will:
>
>     xmlstring mem;
>     func(out mem);
>     mem = null;
>     func(out mem);

Yes, that's clearly a bug in valac, out arguments should be treated like
assignments.

> - There is probably reason for it, but I'll ask anyway. Why weak retvals
>   can't be assigned to var variables? I.e. I can't do:
>
>     var node = doc.new_node();
>
>   where new_node() is 
>
>     public weak Node new_node();
>
>   It would be excellent if "weakness" of the var was also inferred from
>   the retval, as it is a little bit easier to write:
>
>     var n = doc.new_node();
>   
>   instead of:
>
>     weak Node n = doc.new_node();

We don't want local variables to be weak without explicitly specifying
it to avoid too much confusion with memory management. The main issue
here is that Node doesn't support reference counting. I'm planning to
add support for some kind of boxing to transparently add reference
counting to types that don't support it but that probably doesn't help
in this case as you never own this node.

> - libxml functions sometimes take ownership of nodes and vala zeroes the
>   node pointer after passing it using # modifier.
>
>   For example I can't write:
>
>     var r = new Node(null, "root");
>     d.set_root_element(#r);
>     r.new_child(...);
>
>   I have to workaround it with:
>
>     var _r = new Node(null, "root");
>     weak Node r = _r;
>     d.set_root_element(#_r);
>     r.new_child(...);
>
>   I understand that vala can't make any assumptions about validity of
>   the pointer after passing it to the set_root_element(). Passing
>   ownership is passing ownership. But in case of libxml _r would be
>   valid as long as d is valid.

libxml is using a confusing method to manage memory, don't know how to
handle this best. Nodes should either always be owned by a document or
it should always be possible to own a node, whether it's in a document
or not. A GObject binding for libxml would probably make sense.

Do you have any suggestions how Vala could handle it in a sane way?
Maybe we should have an attribute that disables automatic memory
management for the Node class completely and let the developer manage
the memory of such types himself.

Jürg
-- 
Jürg Billeter <j bitron ch>