Re: [anjuta-devel] Change project property interface

[Abderrahim Kitouni <a kitouni gmail com>]

Hello,

              في ر، 21-12-2011 عند 22:19 +0100 ، كتب Sébastien Granjoux:
> Le 21/12/2011 13:58, Abderrahim Kitouni a écrit :
> > Well, it does. Functions like anjuta_project_node_insert_property_info
> > clearly create the nodes added to the list, and this is the only way to
> > add PropertyInfo's to a node (if we remove the gobject property).
>
> Yes, I don't use this function. I'm setting directly the properties_list 
> member. I have added it for you. I think it would be better to set the 
> whole properties info list in one call allowing you to reuse the same 
> list for several nodes.

This is possible, but the list would need to be copied anyway (see below).

> When loading nodes, I could have temporary properties which could have 
> temporary PropertiesInfo structure. It's the case when the properties 
> are declared before the target in Makefile.am. By example if you have
>    test_CFLAGS = -O0
>    bin_PROGRAMS = test
>
> A dummy CFLAGS property is added to a dummy node until we find the 
> target node test. These dummy properties have a temporary property info 
> which is free with the dummy node. To make the distinction, I have added 
> a flag ANJUTA_PROJECT_PROPERTY_STATIC which is cleared for such property.

I wasn't aware of this, and this is something introspection doesn't like
(you could keep it but it shouldn't be used by introspection backends).

> > This could be done in a generic manner by using the user_data field, but
> > I think it should be possible to keep the current C plugins unchanged.
>
> Even if you use the user_data field, you need to have a function to free 
> the data correctly.

Right, but in contrast to the current approach it could be done in the
finalizer (it just has to iterate through the properties freeing their
user_data, and doesn't need to touch the properties lists). Anyway, this
isn't a problem. The C plugins could be kept (mostly) unchanged for now.

> To be clear, even if I'm discussing quite a lot, I would like to make it 
> work with dynamic languages and without too much tricky things in Vala.

Don't worry ;)

> > Try to think in Python: the info list is a Python list, and in order to
> > get this list to the node object (even through a possible
> > set_properties_info) it needs to be converted to a GList, then either
> > its ownership is taken by the node object, or it is freed just
> > afterwards. So the node object needs to own at least the list (even
> > though it doesn't need to own its contents).
>
> How does it work if the object doesn't own the content? the content is a 
> Python structure by example, so it should be converted to a C structure no?

The content is a C struct (in our example AnjutaProjectInfo) wrapped in
a Python object, so as long as the wrapper is kept alive, it won't free
the C struct. Lists and arrays are handled differently since all
languages have their native list types and don't need to wrap the GLib
implementation.

> I have looked as instrospection documentation, it has improved since 
> last time I read it. Indeed, the argument should be marked as transfer 
> none but we expect that the caller keep a valid copy of the parameter. I 
> think it triggers issues similar to call back which is tricky.

The problem doesn't happen with boxed structs, they will not be freed as
long as the wrapping object is alive. We could replace the current
_insert_property_info by a _set_properties_info that takes a (transfer
container) list, but the end result would be the same.

I don't think the memory gain for doing something else is substantial,
so I'd rather keep it like this. (see also my patches in bug 666679)

Regards,
Abderrahim