Re: [anjuta-devel] Change project property interface

[Abderrahim Kitouni <a kitouni gmail com>]

Hi Sébastien,

              في ث، 20-12-2011 عند 22:52 +0100 ، كتب Sébastien Granjoux:
> > The real problem now is that the lists properties and properties info
> > are created by AnjutaProjectNode and so should be freed there. Then what
> > should be done for the content of these lists? A possible solution is to
> > have the node own the properties but not the property info.
>
> The properties and the list are clearly created and owned by 
> AnjutaProjectNode object.
>
> But that's not the case of properties informations and its list. In the 
> autotools project, the properties information is not owned by the 
> AnjutaProjectNode object. It is a constant list. So the node doesn't 
> need to do anything about it.

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).

> > So the dispose (or finalize, I'm not sure) function of AnjutaProjectNode
> > should:
> >     g_list_foreach (self->properties, anjuta_project_property_free);
> >     g_list_free (self->properties);
> >
> >     g_list_free (self->properties_info);
>
> There are 2 issues here.
>
> 1. The properties structure could be extended or contains private data, 
> so it's not always possible to use the generic 
> anjuta_project_property_free function.

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.

> In my idea, this code should goes in the dispose (or finalize) function 
> of an object derived from AnjutaProjectNode and specific to each backend 
> by example a BuildDJNode in your case. Isn't it possible to create such 
> derived object? I have thought that using a real GObject allow such thing.

The problem is that the list is a field in AnjutaProjectNode, and as
such needs to be freed from there. And while things like you propose are
doable in Vala (we need however to tweak generated bindings), it is
impossible to do for dynamic languages.

> Anyway, if it's not possible, we could keep it, as the C will free this 
> list before calling the base function.

I think this is the best way to do it now.

> 2. In my idea, the properties info list shouldn't be freed by the node. 
> It's a constant list, everything is constant here, so it's just useless 
> that each node has its own copy of it. You already don't free each 
> properties info item why do you free the list?

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).

> > name, file, and type are interesting to have (to ease construction),
> > properties and properties_info are more pain than they are worth and
> > should probably be removed. I'm not sure what to do with state however.
>
> Well, you can keep it as it can be useful for construction too.

Ok.

Regards,
Abderrahim