Re: [anjuta-devel] Change project property interface

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

Hi Abderrahim,


Le 04/11/2011 23:08, Abderrahim Kitouni a écrit :
> > The issue of replacing both GList by a virtual method is that currently
> > AnjutaProjectNode has no virtual function.
> The problem is that introspection doesn't allow to assign to a field. So
> right now, it doesn't work in Python.

Then, I think we need to provide functions to do it.


> The problem right now is that the properties and properties_info are
> stored in the AnjutaProjectNode struct but subclasses are responsible
> for managing their memory. So ultimately I'd like to have the lists
> stored in the subclasses themselves, and the only way that I see to
> achieve this is to make the current methods virtual. I'm open to any
> other suggestion.

Ok the problem is clear.

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.


> > > Another change I'd like is to have IAnjutaProject's methods dealing with
> > > properties take the property id instead of a pointer to the property.
> > Is it ok if we provide both?
> I don't think it's worth the trouble (but see below).

I'm not sure neither, perhaps I can check what is the difference in 
speed. So let's use id for the moment. If it's really important it is 
still possible to add them later.


> I'm trying to have an API that's usable both from Vala and Python, and
> currently this seems challenging.

I'm supporting you, in my way. I mean that I'm trying to imagine other 
(complex) solution so if we can find something better :)


> Here are all the uses of the properties API from the project manager

Thanks for this summary.


> (Am I right in thinking that it still doesn't support adding values to a
> map property? If so, we should take this into account when designing the
> API)

Yes, you are right.


>    * know whether a property has been set explicitly.
> (I'm not sure whether the latter is really needed or just a consequence
> of how things are currently implemented).

I think it's useful because properties set explicitly are put first.


> The problem is that if you want to extend the Property structs in a
> backend specific ways, you need the backend to take care of memory
> management for them, but then you can't have them in the base class
> unless you have a uniform way to free them (which isn't easy if they
> aren't GObjects).

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.


> There is another problem with the current api is that it doesn't allow
> one to set the native properties list (I've tried to solve this by
> making it a property, but I don't really like that solution).

I'm agree, I haven't seen the issue in C. I think we need to add 
functions for this.

I think we need something like

   AnjutaProjectPropertyInfo *anjuta_project_property_info_new (const 
gchar *name, const gchar *id, AnjutaProjectValueType type, 
AnjutaProjectPropertyFlags flags, const gchar *description);
   void anjuta_project_node_add_property_info (AnjutaProjectNode *node, 
AnjutaProjectPropertyInfo *info).

The C plugin could extend the AnjutaProjectPropertyInfo object and will 
not use anjuta_project_info_new but this will be useful for python and 
vala plugin.

The anjuta_project_node_add_property_info function will be useful to 
make the GList properties_info member private.


> So here is my proposal:
>    * Make get_native_properties virtual  (transfer container)
>    * Make get_custom_properties virtual (transfer container)
>    * insert_property virtual
>    * remove_property virtual
> I hope this is reasonable, what do you think? did I miss something?

I think it's reasonable and I think you understand how it's working but 
I'm still annoyed to add virtual function to the project node object, 
moreover I would prefer to have constant list, so
  GList *anjuta_project_node_get_native_properties (AnjutaProjectNode 
*node); non virtual (transfer none)
  GList *anjuta_project_node_get_custom_properties (AnjutaProjectNode 
*node); non virtual (transfer none)
  gboolean ianjuta_project_remove_property (IAnjutaProject *obj, 
AnjutaProjectNode *node,  const gchar *id, GError **err) virtual
  AnjutaProjectProperty* ianjuta_project_set_property (IAnjutaProject 
*obj, AnjutaProjectNode *parent, const gchar *id,  const gchar *value, 
GError **err); (transfer none)


This is almost the same functions which are already existing except that 
I have used an string id for remove and set property.

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?

Then for get_native_properties and get_custom_properties, I think we
can use non virtual function if the backend always keep these two lists 
valid.
I'm agree that it could be more efficient to create them only when 
needed if we have few read and more write but I'm even not sure it's the 
case. Moreover, having them always valid means that the list itself 
belong to the node and we can use "transfer none" which is a bit easier 
for the caller. Do you see other advantages of using virtual functions?


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.


Regards,

Sébastien