Re: [anjuta-devel] Change project property interface

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

Hi Abderrahim,


Le 05/11/2011 22:39, Abderrahim Kitouni a écrit :
> I think we're almost there :-)

Yes, we have different ideas but we are getting closer and closer. I 
really appreciate such discussion. You find it perhaps a bit slow but I 
need some time to find better arguments or change my mind.


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

I think that my argument which is to avoid virtual functions in node 
object is not very good because we already have at least a virtual 
function finalize or dispose to free the object.

If we compare
AnjutaProjectProperty* ianjuta_project_set_property (IAnjutaProject 
*obj, AnjutaProjectNode *parent, const gchar *name,  const gchar *value, 
GError **err);
to
AnjuaProjectProperty* anjuta_project_node_set_property 
(AnjutaProjectNode *parent, const gchar *name,  const gchar *value, 
GError **err);

The difference is not that big. It's easy to implement the first 
function using the second one (the opposite is possible but more 
difficult). In the autotools project, it's easier to use the first 
function because I'm using a common commands queue.

I think it's better that the project doesn't mess with the internals of 
the nodes too and I have done it more or less (it has evolved other the 
time) in the autotools project. But it's easy to do it with the first 
function too.


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

Ok, I will try to compile it but I think vala compiler is not working 
here. My system is quite old and could need an upgrade.


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

Ok, I will call it data like in GList.


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

Ok. Indeed removing such property information makes no sense.


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

There is an important difference between 
anjuta_project_node_add_property_info and ianjuta_project_set_property.

The first function doesn't change anything to the project, it is only 
used to initialize project structure, it should be called only by the 
backend plugin.

While the second one really changes the project data and will be called 
by backend users.

Based on this remark, I think it makes sense to keep 
ianjuta_project_set_property instead of anjuta_project_node_set_property 
to make the difference more clear. anjuta_project_node_set_property will 
probably exists but it is an internal function of the backend, it is not 
part of the API.


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

I have thought again about this and my proposal is not working.

If I do it like I have proposed I get
AnjutaProjectProperty -> AnjutaProjectPropertyInfo -> AmpPropertyInfo
                      -> AmpProperty
The autotools backend considers that all properties are AmpProperty but 
it is not true because a default property (included in 
AnjutaProjectPropertyInfo) will be a AnjutaProjectProperty only.

The only difference between an AnjutaProjectProperty and a AmpProperty 
is a pointer on the token corresponding to the property value. A default 
property obviously don't have such token. So in theory it could still 
work. But in practice, it means I will have to check if a 
AnjutaProjectProperty has this token pointer or not. The goal of doing 
such thing is to always be able to return a property value to avoid 
checks, we don't reach it.


So here is another proposal that should be better for you too.

struct _AnjutaProjectProperty
{
    gchar *value;
    gchar *name;
    AnjutaProjectPropertyInfo *info;
}

struct _AnjutaProjectPropertyInfo
{
    const gchar *id;
    AnjutaProjectValueType type;
    AnjutaProjectPropertyFlags flags;
    const gchar *description;
    AnjutaProjectProperty *default;
}


Regards,

Sébastien