Re: [anjuta-devel] Change project property interface

[Abderrahim Kitouni <a kitouni gmail com>]

Hello Sébastien,

I think we're almost there :-)

              في س، 05-11-2011 عند 12:43 +0100 ، كتب Sébastien Granjoux:
> But I think there is another possibility which is:
> - Add non virtual function to allocate and free properties.
> - Python and Vala plugin could use them and will have to maintain extra 
> data in another structure, probably a hash table. If needed we can add a 
> pointer in the property structure.
> - C plugin don't need these function and could extend the C structure 
> directly.

I'd rather do something that can be used in the same way from all three
languages.

> A backend could extend a property without changing the structure. We 
> could add a user_data parameter in the property just for it. Else the 
> backend could maintain a hash table to link additional data.

This is a good idea.

> I suppose that in your proposal insert_property and remove_property are 
> virtual function of the node object. Currently these are virtual 
> functions of the project object so we need to keep the project node 
> around but I don't see an issue. Do you see other drawback of using the 
> current functions?

I feel that the role of the project object is to keep the nodes and any
other representation of the project structure (like the AnjutaToken) in
sync, and not to mess with the internals of the nodes.


> Do you have already started to write a backend in python or vala that I 
> could read? I would like to see how it could be written.

Here you go: https://bitbucket.org/abderrahim/anjuta-buildj (if you want
to compile it run gnome-autogen.sh && make && make install)

So taking your comments into account, here is another proposal:
* Add a void *user_data to both AnjutaProjectProperty and
AnjutaProjectProperty (this could be called something else).
* Add anjuta_project_node_add_property_info(). Since the property infos
aren't supposed to change, we don't need a remove function. The list and
its content are freed when the instance is finalized, and the subclasses
are responsible for freeing the user_data.
* I'd like to do something similar for the properties themselves, but
the fact that properties can be removed makes things a bit more
difficult. Although I don't like this solution, I think we can do the
same by freeing the user_data in ianjuta_project_remove_property().

The rest being as you described. The only thing that annoys me now is
what I called "ad-hoc subclassing": the fact that you want to use a
PropertyInfo as a Property.

Regards,
Abderrahim