Re: [anjuta-devel] Change project property interface

[Sébastien Granjoux <seb sfo free fr>]

Hi Abderrahim,


Le 20/12/2011 18:43, Abderrahim Kitouni a écrit :
> Well, for GObject introspection to work, you need to enforce a memory
> management scheme. Having a possibility to short-circuit that scheme for
> C may be doable, even though I don't like this much.

Ok.


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


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

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.

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


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?


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


Regards,

Sébastien