Re: [anjuta-devel] Change project property interface

[Abderrahim Kitouni <a kitouni gmail com>]

Hello Sébastien,

sorry for the late response, I've had a busy week.

> > Do we need to add a set_map_property? (I also like
> > the symmetry with anjuta_project_node_get_property and
> > anjuta_project_node_get_map_property. The same goes for
> > anjuta_project_property_new below.
>
> As I have defined it the anjuta_project_property_new already take a name 
> argument so it could be considered as anjuta_project_map_property_new. I 
> think it's better to keep it as anjuta_project_property_new as the name 
> is simple enough.

Of course. I didn't notice the name argument to
anjuta_project_property_new, so your proposal is fine.

> Then, for set and get functions here 3 new proposals.
>
> 1. Have only ianjuta_project_set_property (AnjutaProjectNode *parent, 
> const gchar *id, const gchar *value) and a map property should use a 
> value with the form "name=value".

> 2. Have only ianjuta_project_set_property (AnjutaProjectNode *parent, 
> const gchar *id, const gchar *value, const gchar *name) and non map
> property can pass a NULL name.

> 3. Have bother functions ianjuta_project_set_property (AnjutaProjectNode 
> *parent, const gchar *id, const gchar *value) and 
> ianjuta_project_set_map_property (AnjutaProjectNode *parent, const gchar 
> *id, const gchar *value, const gchar *name)

> I will do the same for all related public functions: 
> ianjuta_project_set_property, ianjuta_project_remove_property, 
> anjuta_project_node_get_property.

I think anjuta_project_node_get_map_property is important as we would
otherwise have to return a list of properties that needs to be iterated
over to find the property one is looking for, and the function would be
useless. So for get_property, solution 1 is not an option.

Then I prefer solution 3 as it seems cleaner, but solution 2 is also
possible.

> I think it's better to anjuta_project_property_new as it is (like 
> solution 2).
I agree.

> > * I'd prefer to have the list owned by the node, so I don't really like
> > this.
>
> Well, it doesn't means that the list is not owned by the node, all node 
> could get a reference on it. I think it's done by default with a python 
> list. Anyway, I will keep it as it is.

What I mean by "owned by the node" is that each node has its (shallow)
copy of the list that gets freed with the node. I think this would
simplify memory management. Perhaps it is better to leave it as is for
now, so we don't have many moving parts.

> Yes, but it's not a class object at least in the autotools backend. I 
> mean the difference between two node could be only this list of properties.

Then I misunderstood what you meant by "it is shared by all nodes of the
same type". Anyway, we can leave it as is for now and come back again
later.

> > Property could use setters. Getters are not strictly
> > necessary but may be a good idea for symmetry.
>
> It's as you want. Let's say I will try to make all this changes first, 
> then if you need setter or getters you can ask them to me or add them 
> directly.

Ok.


For now, I think the best would be to start implementing things and see
how it goes. I won't be able to help for now but maybe it will be better
in a week or two.


Thanks and regards,
Abderrahim