GNOME.org
 

Re: [anjuta-devel] Change project property interface

Hi Abderrahim,


Le 02/11/2011 22:24, Abderrahim Kitouni a écrit :

Thanks for taking the time to think about this, I think it's going in
the right direction, but I'd rather push it further. See below for my
remarks.
That's why I have send you this mail, I have expected you will have some comments. 


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

Does the name really need to be here (rather than in the info)?
It's used for map properties. By example in autotools, it is used for installation directories. You can defined custom directories for installing your software by defining a variable named with the prefix dir with a value corresponding to the installation dir by example 
anjutadocdir = $(docdir)
In such case, anjutadocdir is the name while the value is $(docdir). I think we could use this name pointer for something else if we defined new kinds of variables.
In this case, we could have use a value equal to "anjutadocdir = $(docdir)" but this force the use of equal sign by example which can annoying if it is allowed as a variable name in one project backend. 




struct _AnjutaProjectNode
{
        GInitiallyUnowned parent_instance;

        /*<  private>*/
        AnjutaProjectNode       *next;
        AnjutaProjectNode *prev;
        AnjutaProjectNode       *parent;
        AnjutaProjectNode *children;


Are the following also considered private? If not, there should be a /*<  public>*/
here.
I have copied the current code here. But at least next is used in the autotools project so it could be better to have them public. But if you think it's better we can perhaps make them private. 



        AnjutaProjectNodeType type;
        AnjutaProjectNodeState state;

        GList *properties_info;
        GList *properties;


Since the memory management of these two lists are done by subclasses,
I'd rather replace them with virtual methods.


You means for both GList or for type and state too?
The issue of replacing both GList by a virtual method is that currently AnjutaProjectNode has no virtual function. Then it's not really more flexible because both lists are already created by the project backend, so it can use a hash table or anything to keep the properties, the only additional requirement is that it has to create these two lists.
If we have a virtual function, we could create the list at runtime but we still have to create them and the caller should take care of freeing them.
The only solution to avoid creating them is to have iterator but I think it's too complex for this case. 



I'm afraid this won't work with introspection. If we really need fast
comparison, we should use GQuark instead, but that's probably not worth
the trouble.
Well, I don't expect much properties. So string comparison could be enough. The nice thing with g_intern_string is that I don't need to change the interface to use them and be faster. 



The problem with this is that introspection doesn't really like ad-hoc
subclassing; we can probably get it to work, but I'd rather find
something else. In what cases it might be interesting to use a
PropertyInfo as a Property?
I haven't checked exactly because currently it's working like this. I think it's useful when you have a default value for a property, you can look for a property and always get a valid result. 



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?
Do you still have issue for properties memory allocation or is it more clear now? 


Regards,

Sébastien
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]